Gericom

Members
  • Content count

    13
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Gericom

  • Rank
    Member
  • Birthday September 27

Profile Information

  • Gender
    Male
  1. Gericom

    Hamster's SDRAM_Controller

    This is my mapping report: +---------------------------------------------------------------------------------------------------------------------------------------------------------+ | IOB Name | Type | Direction | IO Standard | Diff | Drive | Slew | Reg (s) | Resistor | IOB | | | | | | Term | Strength | Rate | | | Delay | +---------------------------------------------------------------------------------------------------------------------------------------------------------+ | CLK | IOB | INPUT | LVTTL | | | | | | | | RX | IOB | INPUT | LVTTL | | | | | | | | SDRAM_ADDR<0> | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_ADDR<1> | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_ADDR<2> | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_ADDR<3> | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_ADDR<4> | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_ADDR<5> | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_ADDR<6> | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_ADDR<7> | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_ADDR<8> | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_ADDR<9> | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_ADDR<10> | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_ADDR<11> | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_ADDR<12> | IOB | OUTPUT | LVTTL | | 12 | SLOW | | | | | SDRAM_BA<0> | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_BA<1> | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_CKE | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_CLK | IOB | OUTPUT | LVTTL | | 12 | SLOW | ODDR | | | | SDRAM_CS | IOB | OUTPUT | LVTTL | | 12 | SLOW | | | | | SDRAM_DQ<0> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | SDRAM_DQ<1> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | SDRAM_DQ<2> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | SDRAM_DQ<3> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | SDRAM_DQ<4> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | SDRAM_DQ<5> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | SDRAM_DQ<6> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | SDRAM_DQ<7> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | SDRAM_DQ<8> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | SDRAM_DQ<9> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | SDRAM_DQ<10> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | SDRAM_DQ<11> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | SDRAM_DQ<12> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | SDRAM_DQ<13> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | SDRAM_DQ<14> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | SDRAM_DQ<15> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | SDRAM_DQM<0> | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_DQM<1> | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_nCAS | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_nRAS | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | SDRAM_nWE | IOB | OUTPUT | LVTTL | | 12 | SLOW | OFF | | | | TX | IOB | OUTPUT | LVTTL | | 8 | FAST | | PULLUP | | | dac_out | IOB | OUTPUT | LVTTL | | 12 | FAST | | | | | dac_out2 | IOB | OUTPUT | LVTTL | | 12 | FAST | | | | +---------------------------------------------------------------------------------------------------------------------------------------------------------+ Could it be related to the SLEW rate too? For some pins it seems to be SLOW.
  2. Gericom

    Hamster's SDRAM_Controller

    Were you talking to me or the OP? I've done some tests with writing audio to the sdram and playing it through a delta-sigma dac, all memory mapped to the microblaze, and that seems to work very well, so everything is solved for me. Also, I have mapped everything to the microblaze by using it's io bus, which makes it possible to access the sdram as if it's a continuous memory region on the chip and the dac as memory mapped io. This is the c code for storing audio send over uart to the sdram and playing it. #include <xparameters.h> #include <xiomodule.h> #include "xil_cache.h" #include <xenv.h> #include <stdbool.h> #define REG_DAC_DATA (*((volatile u32*)0xF0000010)) #define REG_DAC_DATA2 (*((volatile u32*)0xF0000014)) #define SDRAM_START 0xD0000000 int nrSamplesInSDRAM = 0; int curSample = 0; u16* sndPtr = (u16*)SDRAM_START; void timerTick(void* ref) { if(nrSamplesInSDRAM > 0) { u16 val = *sndPtr++; REG_DAC_DATA = val; REG_DAC_DATA2 = val; curSample++; //curSample+=2; if(curSample >= nrSamplesInSDRAM) { curSample = 0; sndPtr = (u16*)SDRAM_START; } } } XIOModule System; void uartRead(u16 numBytes, u8 *data) { u16 counter = 0; while(counter < numBytes) { u16 numRead; while((numRead = XIOModule_Recv(&System,data,numBytes-counter)) == 0); counter += numRead; data += numRead; } } int main() { Xil_DCacheDisable(); nrSamplesInSDRAM = 0; curSample = 0; sndPtr = (u16*)SDRAM_START; XIOModule_Initialize(&System, XPAR_IOMODULE_0_DEVICE_ID); microblaze_register_handler(XIOModule_DeviceInterruptHandler, XPAR_IOMODULE_0_DEVICE_ID); XIOModule_Start(&System); XIOModule_CfgInitialize(&System,NULL,1); XIOModule_SetBaudRate(&System, 750000);//115200); xil_printf("==== START ====\n\r"); // Set the interval of the PIT. Default counter clock is system clock. XIOModule_SetResetValue(&System, 0, 108000000 / 32000);//2250);//3375); // Register interrupt handler XIOModule_Connect(&System, XIN_IOMODULE_PIT_1_INTERRUPT_INTR, timerTick, NULL); // Enable interrupts XIOModule_Enable(&System, XIN_IOMODULE_PIT_1_INTERRUPT_INTR); // Specify PIT is to automatically reload. Without this, ISR runs once XIOModule_Timer_SetOptions(&System, 0, XTC_AUTO_RELOAD_OPTION); XIOModule_Timer_Start(&System, 0); microblaze_enable_interrupts(); while(1) { if(nrSamplesInSDRAM < 4 * 1024 * 1024) { uartRead(8 * 1024, &((u16*)SDRAM_START)[nrSamplesInSDRAM]); nrSamplesInSDRAM+=8 * 1024 / 2; } } }
  3. Gericom

    Hamster's SDRAM_Controller

    Sorry for bumping this topic, but is there any progress on this? I'm also trying to implement sdram reads and writes from the microblaze using it's i/o bus, but I am also experiencing problems with the upper 16 bits which are for some reason stuck on the value that was written before. It really sounds like some neasty timing problem in which the (16 bit) value previously written is still on the data bus of the sdram and then read as the next top 16 bits. Could it anyhow be related to the 100 MHz clock I'm using? I used the sdram before with a slightly higher rate of 108 MHz, which worked fine. I will try using 108 MHz and report back if it works. Edit: Switching to 108 MHz doesn't seem to work either. I'm still having the same problem. Edit2: Appearently replacing the line signal data_ready_delay : std_logic_vector( 3 downto 0); by signal data_ready_delay : std_logic_vector( 4 downto 0); in the sdram controller did the trick. That last line was there already commented out, so I think @hamster has been experimenting with this too. It looks to me as if the problem has been solved this way. The 2 parts of the 32 bit value are also not reversed anymore now.
  4. HDMI->YPbPr shouldn't be too difficult. You could use 3 r2r ladders in combination with hamsters hdmi wing. You have to generate composite sync. For RGB->YUV you can use an ip core of xilinx.
  5. Gericom

    HDMI input

    HDMI to PAL Composite with the hdmi wing and 10 resistors. The 5 double picture is, because the input signal is 60hz, and the pal composite is 25hz.
  6. Gericom

    HDMI input

    Great! Can I buy your wing somewhere?
  7. Gericom

    HDMI input

    Great! Hope it works good.
  8. Gericom

    High Speed USB

    Hello everyone. I am planning on making a simple usb capture device (I know they exist, but I want to do it myself), that can capture analog rgb video from scart. I know how to do this (I have 2 2 channel high speed adc's and a lm1881 sync separator), but before I begin, I want to be sure I can send the required amount of data over the usb. Using the serial on the papilio this is not possible, so I am considering buying an evaluation board for the FT232H high speed usb chip (UM232H). The required speed needs to be arround 35MByte/s for 24 bit rgb, but if needed I can lower it by using 16 bit instead. According to the datasheet of the FT232H, it should be able to do speeds up to 40MByte/s. My question is if this is possible with the FT232H. Or is there maybe another chip/evaluation board I can better use instead.
  9. Gericom

    Playing back audio from SDRAM.

    Nice! I think I will give this a try. Edit: Lol! Works like a charm!
  10. Gericom

    Confusing SDRAM

    Yea, I think so.I don't know if waiting for requested data, before doing a write is the solution. That would require some more testing.
  11. Gericom

    Confusing SDRAM

    Thanks! The dots did also appear with those color bars, so it's definitly not the uart. After the dots have appeared, they don't move or something, so I think it must be a writing issue. Maybe it is related to a delayed refresh or something? Edit: I added interlacing! The dots are still there. In this picture, you can see the dots very good: This is the original picture: Edit2: After changing the pixel clock from 50MHz to 54MHz (4x13.5MHz), I realised that I forgot to wait for the last pixels to come out of the sdram. And now the dots are gone!
  12. Gericom

    Confusing SDRAM

    Thanks for your quick response, but I don't understand it completely yet. The way it works right now is like this: MainProc: Generates the composite video ConvProc: If the current line is >= 23 and < 309, the right color bar color (rgb) is chosen, based on the pixel that will be converted. The RGB values are fed into a RGB->YUV converter ip core, and the active_video_in signal is set high. When the active_video_out signal goes high, I copy the converted YUV values to the line buffer, and the MainProc will use this buffer to modulate the YUV values in real time. The first part with the RGB source, should come from the SDRAM instead (or the FIFO that is connected to it). But where do I have to do the read cycles? In an apart process? Edit: I got it working with the SDRAM now, but I still have a lot of weird problems. This for example: It should look the same as the picture in the first post, but it is about 60% smaller. (the pink on the right is just memory that is not written) This is very weird, and it seems related to reading. If I change the clock of the read process from 100MHz to 50MHz, the picture becomes twice as big as the picture in the first post. This should not happen, since each pixel should be inserted in the fifo once. And sometimes I get weird dots at a couple of places, as if the data was not transfered correctly, and when writing, I have to put the data in reversed order, to get the right order at the output. (if the output has to be XRBG, the input has to be BGXR. R,G,B and X are all bytes) Edit2: I now got it working. It turned out, that I don't need a fifo or a separate process. I will try to get a picture loading from the flash memory soon, so I can show it working. Edit3: This picture is uploaded using serial rather than the flash, but it works! The lines are all doubled, because I have not implemented interlacing yet, and I send the line number as a byte over the serial, so that's why the top of the picture is repeated at the bottom (after 255 lines). At some places you can also see some little dots, caused by the sdram, which seems to not recieve correct data at some times.
  13. Gericom

    Confusing SDRAM

    Hi everyone, I am working on a PAL Composite Video generator, and with color bars (no frame buffer), it works great. Now I am at the point that I need a frame buffer, and since the internal memory of the Spartan-6 would never be enough for a full 720x288x3 pixel frame buffer, I hoped to be able to use the SDRAM for this. I have tried, but the results are very bad. I think it is not fast enough or something. I used hamsters SDRAM controller. Is it possible to use the SDRAM as a frame buffer, and is it fast enough? The process that needs the data (RGB->YUV conversion), runs at 50 MHz, but I think it should be possible to do this at 12.5 MHz aswell. According to hamsters wiki, the data should be available at the next clock cycle. But at the top of the controller file, stands that it may take 16 cycles. I don't know if this is enough information, but I hope someone can help me with this. Edit: Here is a capture of the color bars.