mkarlsson

Members
  • Posts

    296
  • Joined

  • Last visited

  • Days Won

    23

Everything posted by mkarlsson

  1. Great! Yeah, I did the same fix in butterfly.cpp to make it work on the same cmd line. I also fixed another thing that confuses a lot of people - if there is a problem with the JTAG connection between the FTDI chip and the FPGA (bad board or opening the wrong FTDI device) then one of the most cryptic error message will shop up: Invalid chain position 0, position must be less than 0 (but not less than 0). So I patched get_id at top of butterfly.cpp to look like this (the added code in italic) so it's more clear what the problem is: unsigned int get_id(Jtag &jtag, DeviceDB &db, int chainpos, bool verbose) { int num=jtag.getChain(); unsigned int id; if (num == 0) { fprintf(stderr, "No JTAG device found, aborting.\n"); return 0; } // Synchronise database with chain of devices. for(int i=0; i<num; i++) { int length=db.loadDevice(jtag.getDeviceID(i)); if(length>0) jtag.setDeviceIRLength(i,length); else { id=jtag.getDeviceID(i); fprintf(stderr, "Cannot find device having IDCODE=%08x\n",id); return 0; } } if(jtag.selectDevice(chainpos)<0) { fprintf(stderr, "Invalid chain position %d, position must be less than %d (but not less than 0).\n",chainpos,num); return 0; } const char *dd=db.getDeviceDescription(chainpos); id = jtag.getDeviceID(chainpos); if (verbose) { printf("JTAG chainpos: %d Device IDCODE = 0x%08x\tDesc: %s\n", chainpos,id, dd); fflush(stdout); } return id; } Magnus
  2. BTW, I would be concerned about the last line above, the high number of retries indicates that there is an issue with your USB link (bad cable etc.). This is what I see when I program a Papilio Pro: Using built-in device list JTAG chainpos: 0 Device IDCODE = 0x24001093 Desc: XC6SLX9 Uploading "tools/bscan_spi_lx9_qfp144.bit". DNA is 0xf9e7a182038fb0ff Done. Programming time 553.0 ms Programming External Flash Memory with "ISE/plustoo_top.bit". Found Macronix Flash (Pages=32768, Page Size=256 bytes, 67108864 bits). Erasing : ......Ok Verifying : ......Pass Programming : ......Ok Verifying : ......Pass Done. SPI execution time 15932.9 ms USB transactions: Write 6851 read 6682 retries 0 Magnus
  3. As I said in the other thread (http://forum.gadgetfactory.net/index.php?/topic/2515-papilio-prog-reconfig-bug-workaround/) the fix for this is simple - just update the Reconfigure() routine in progalgxc3s.cpp like the way the current xc3sprog code does it and recompile. If you want to try it, here is a link to a version with this fix implemented (windows version) : http://www.saanlima.com/download/papilio-prog.exe Magnus
  4. Yeah, this is a known bug (-r not working). See http://forum.gadgetfactory.net/index.php?/topic/2515-papilio-prog-reconfig-bug-workaround/ Magnus
  5. Try this cmd line: sudo papilio-prog -f chapter7.bit -b bscan_spi_lx9.bit -v -sa -r Magnus
  6. constant sdram_address_width : natural := 22; constant sdram_column_bits : natural := 8; constant sdram_startup_cycles: natural := 10100; -- 100us, plus a little more constant cycles_per_refresh : natural := (64000*100)/4196-1; The constants are there so you can adapt the memory controller to different kind of memory chips. The constants used above are valid for the memory chip on Papilio Pro. I know that the memory has words of 16 bits, so if i need to read/write 32 bits i need to specify 2 addresses, right? No, just one address. The 32-bits use up two consecutive memory locations in the 16-bit SDRAM. The width of cmd_address is one less than the address width of the SDRAM (21 vs.22 bits). One way to look at it is to say that cmd_address is SDRAM address bits 21-1, and that the controller is internally appending SDRAM address bit 0 ('0' for the first 16 bits and '1' for the second set of 16-bits). In addition I read that each address is composed of 8 bits to specify the column (A0-A7), A8,A9,A11 nothing and A10 to enable/disable precharge; plus there are B0-B1 to specify the bank address. I would like to know if i have to deal with those things of if I have to act like i have a 22bit address memory. The whole purpose of the memory controller is to hide all the nasty details of the memory chip from the user. From the users perspective it looks like a 32-bit wide memory with 21 address bits (i.e. 8MB) and with individual byte-write enables. This is what hamster writes about how to use the memory controller:The use of the SDRAM controller is pretty simple. Any time that CMD_READY is asserted by the memory controller, and CMD_ENABLE is asserted by your logic the address, data, byte enable flags and write flag will be registered by the controller, and the command will be carried out as soon as possible. Should you want to write to memory, that is all that you have to do. To perform reads the value of the cmd_data_in cmd_byte_enable inputs are ignored. As soon as the data has been read it will be presented on data_out, and data_out_ready will be asserted for one cycle. This may happen many cycles after the command is issued (depending on when a refresh cycle is due), but sometime during the command execution CMD_READY will be asserted so you can queue up the next transaction. Magnus
  7. I'm not sure what part is confusing to you, the interface to the memory controller is quite simple. clk: 100 MHz clock signal to the controller. All interface inputs and outputs are synchronous to this clock reset: reset signal to the controller (like power-on reset) cmd_ready: output from the controller, indicating if it's ready to accept a command (ready if '1') cmd_enable: input to the controller, '1' means that you are issuing a new command (the command is only accepted if cmd_ready is '1') cmd_wr: input to the controller, specifies if the command is a write command (cmd_wr = '1') or read command (cmd_wr = '0') cmd_address: input to the controller, specifies the memory address for the command (note that this is a 32-bit word address) cmd_byte_enable: 4-bit input to the controller used when writing (one bit for each byte). '1' means that the corresponding byte is written, '0' means that it will not be written cmd_data_in: 32-bit input to the controller with the data that you want to write data_out: 32-bit output from the controller with the data from the last read command (only valid when data_out_ready == '1') data_out_ready: data_out from the last read command is available For example, to write all four bytes in a 32-bit data word to a memory location you set cmd_wr = '1', cmd_address = <your memory address>, cmd_byte enable = '1111', cmd_data_in = <your data>, and cmd_enable ='1'. The controller will respond with changing cmd_ready from '1' to '0', at which point you can set cmd_enable = '0'. The next command can be issued when cmd_ready is changed from '0' to '1'. To read a 32-bit data word from a memory location you set cmd_wr = '0', cmd_address = <your memory address>, cmd_byte_enable = '0000' (or whatever), cmd_data_in = 32-bit 0 (or whatever) and cmd_enable = '1'. The controller will respond with changing cmd_ready from '1' to '0', at which point you can set cmd_enable = '0'. The 32-bit read data is available at data_out when data_out_ready = '1' Note that cmd_wr, cmd_address, cmd_byte_enable and cmd_data_in are "don't care" if cmd_enable is '0', they only matter when cmd_enable = '1' and cmd_ready = '1'. Magnus
  8. The memory controller is written so that a CPU with 32-bit data bus can access the memory. The memory controller is creating the illusion of a 32-bit memory system by reading or writing two 16-bit words for each 32-bit access. You can modify his controller so that it's only reading or writing one 16-bit word for each access if that's what you need. However, that would reduce the data rate by almost a factor of 2. A better way would be to actually increase the data bus width to 64-bits so that each access is a burst of four 16-bit words, that would almost double the data rate and hopefully give you enough bandwidth so that you can support a VGA framebuffer (25 MB/s). Magnus
  9. That's good. I based my comment about bursting based on the interface described at the top of the post - no burst count etc., just single word read/write. Magnus
  10. Another comment is that SDRAM is optimized for burst access - once you have opened a "row" you can read or write data sequential from/to that row in a burst (one word per clock), making this kind of memory very good for a frame buffer where you typically access data sequentially. However, this needs a memory controller written specifically for this use case. I think hamsters SDRAM controller is written with a 32-bit CPU in mind and do not provide burst access. BTW, the MiST FPGA board have the same SDRAM chip as Papilio Pro and they wrote a memory controller that makes the SDRAM look like SRAM that can be accessed at 8 MHz (i.e. 16 MB/s). I ported their Macintosh PlusToo project to Papilio Pro and wrote a post about it here: http://forum.gadgetfactory.net/index.php?/topic/2485-plustoo-macintosh-plus-clone-running-on-papilio-pro/ You can download the project and look at the sdram controller module. It might not be fast enough for your project but you might be able to modify it to do burst access. Magnus
  11. Hi Leon, The only "VGA"-sh thing about the camera is the pixel resolution (640x480). It sends data at 30 fps and there is no VGA timing mode that match that. See http://martin.hinner.info/vga/timing.html I think you have to buffer the image somehow if you want to display it on a VGA monitor (like what hamster did). Or stream it out via serial port and display it on the PC monitor (like what voelker did). Cheers, Magnus
  12. You can't expect to see 3.3v on the output pin. What IO standard are you using? LVTTL? LVCMOS33? The Spartan-6 data sheet specifies that for LVTTL the Voh (V output high) is minimum 2.4V and for LVCMOS33 Voh is minimum Vcco - 0.4V (i.e. min 2.9V). So if you are using LVTTL then 2.5V is well within spec. For more info see Table 9 on page 10 in this data sheet: http://www.xilinx.com/support/documentation/data_sheets/ds162.pdf Magnus
  13. For more info see: https://www.llnl.gov/news/nih-taps-lab-develop-sophisticated-electrode-array-system-monitor-brain-activity The NIH project is a collaboration between LLNL's Neural Technology Group; the laboratory of Loren Frank at University of California, San Francisco (UCSF); Intan Technology; and SpikeGadgets. Housed at the Center for Bioengineering, the Neural Technology Group will work with UCSF researchers to design and build electrode arrays that can record hundreds to thousands of brain cells simultaneously. Their goal is to develop 1,000-plus channel arrays that can eventually be expanded to 10,000 channels. These arrays will use new microchips designed at Intan and will send data to a system developed at SpikeGadgets. UCSF will coordinate these efforts and test the technologies. The arrays will penetrate multiple regions of the brain without interfering with normal functions during the experiments, allowing for detailed studies of brain circuits that underlie behavior. "This collaboration combines the engineering talent of LLNL with UCSF's expertise in neural recording and modulation systems, and the design and programming skills of Intan and SpikeGadgets," Frank said. "The result will be a system that will help us understand how different brain areas communicate and carry out complex mental functions."
  14. And I happen to work on a system that samples up to 1024 analog signals each 16-bit at 30 kHz sampling rate using up to 16 ADCs, each with a 64 ch mux All done with an Spartan6 LX16 and streaming the data out using a TMDS link (i.e. like HDMI but just clock and data) at 78.6 MB/s. using regular HDMI connectors and cables. For something like this you definitely need an FPGA. Here is a picture of a 640 ch system. FPGA board to the right with micro-HDMI connector for power and data, 5 ADC boards in the middle, each with 2 ADCs (i.e. 128 ch each), and LVDS terminator board to the left. The ADCs are connected to the FPGA using SPI with LVDS signaling (CS, CLK, MOSI, 16x MISO).
  15. I think the current papilio-prog code works for Spartan3 but not Spartan6. This is what the papilio-prog reconfigure code looks like (in progalgxc3s.cpp): void ProgAlgXC3S::Reconfigure(){ jtag->shiftIR(&JPROGRAM); jtag->shiftIR(&BYPASS);}And this is the modified code that I have been using (and works for Spartan6) based on the current xc3sprog code: void ProgAlgXC3S::Reconfigure(){// jtag->shiftIR(&JPROGRAM);// jtag->shiftIR(&BYPASS); switch(family) { case 0x0e: /* XC3SE*/ case 0x11: /* XC3SA*/ case 0x13: /* XC3SAN*/ case 0x20: /* XC6S*/ break; default: fprintf(stderr, "Device does not support reconfiguration.\n"); return; } /* Sequence is from AR #31913 FFFF Dummy Word 9955 SYNC 850c Type 1 Write to CMD 7000 REBOOT command 0004 NOOP 0004 NOOP */ byte xc3sbuf[12]= {0xff, 0xff, 0x55, 0x99, 0x0c, 0x85, 0x00, 0x70, 0x04, 0x00, 0x04, 0x00}; /* xtp038.pdf FFFF Dummy Word AA99 Sync Word 5566 Sync Word 30A1 Type 1 Write 1 Word to CMD 000E IPROG Command 2000 Type 1 NO OP */ byte xc6sbuf[12]= {0xff, 0xff, 0x55, 0x99, 0xaa, 0x66, 0x0c, 0x85, 0x00, 0x70, 0x04, 0x00}; jtag->shiftIR(&JSHUTDOWN); io->cycleTCK(16); jtag->shiftIR(&CFG_IN); if(io->getVerbose()) fprintf(stderr, "Trying reconfigure\n"); if(family == 0x20) /*XC6S*/ jtag->shiftDR(xc6sbuf, NULL, 12*8 ); else jtag->shiftDR(xc3sbuf, NULL, 12*8 ); jtag->shiftIR(&JSTART); io->cycleTCK(32); jtag->shiftIR(&BYPASS); io->cycleTCK(1);// jtag->setTapState(Jtag::TEST_LOGIC_RESET);}Magnus
  16. In Verilog you can also use $readmemh to initialize the ROM data. Here is an example of a 1Kword 16-bit ROM initialized from a file: reg [15:0] mem [1023:0]; reg [15:0] romDataOut; initial $readmemh("rom.mem", mem); always @(posedge clk) romDataOut <= mem[memoryAddr]]; The rom.mem file is just a list of hexadecimal values for the ROM data, like this: 4d1f 8172 0040 002a 0075 6000 0056 6000 . . Magnus
  17. I think I know what it is. The video output is not blanked during non-display time so the noise is probably happening during horizontal retrace. Magnus
  18. Another option is to first flash the plustoo.bit file that's in the zip archive, it will store the rom and system disk data in flash, then load or flash your new bit file like you normally do. The rom and disk data will remain in flash since only the configuration area will be erased when you flash your bitfile. The 'promgen' tool included with ISE can be used to the same effect but promgen is a little more userfriendly as the result is a bitfile that can be used with fpga/papilioprog. The bitfile created by Mike Field's bitmerge program can be written to flash with fpga/papilioprog just like any other bitfile. Magnus
  19. The MiST guys made a lot of changes to the code, like using a different version of the 68K CPU and the VIA chip, added support for keyboard and sound, SDRAM support, and changed memory access timing quite a bit. They are also working on adding SCSI HD support via SD card. One major difference between the MiST version and the Papilio Pro/Pipistrello version is how the ROM and System disk data is loaded to RAM, they have a separate ARM processor that loads it via SPI, while I wrote a module that reads the ROM and floppy data from the serial flash chip at power up Magnus
  20. This is based on the MiST port of Big Mess o' Wires PlusToo project. MiST uses the same SDRAM as Papilio Pro so that made it quite easy. To use this you need to flash the bitfile plustoo.bit since it contains the ROM code and the 800KB system disk data in addition to the FPGA configuration data. The floppy is read-only. BTW, this uses about 98% of the slices in the LX9 so it's quite full The setup uses the LogicStart megawing for VGA. PS/2 keyboard and mouse needs to be hooked up to A3 - A6 (normally used for 7 seg display). # PS/2 mouse NET mouseClk LOC = "P58" | IOSTANDARD = LVCMOS33 | PULLUP; # A3 NET mouseData LOC = "P61" | IOSTANDARD = LVCMOS33 | PULLUP; # A4 # PS/2 keyboard NET keyClk LOC = "P66" | IOSTANDARD = LVCMOS33 | PULLUP; # A5 NET keyData LOC = "P67" | IOSTANDARD = LVCMOS33 | PULLUP; # A6 On my setup the video is quite noisy but that could be due to my monitor. You can grab the whole ISE project (including bit file) here: http://www.saanlima.com/download/Papilio_Pro/PlusToo_Papilo_Pro.zip Links: Big Mess o' Wires: http://www.bigmessowires.com/ MiST PlusToo forum: http://atari-forum.com/viewtopic.php?f=101&t=28648 PlusToo on Pipistrello: http://forum.gadgetfactory.net/index.php?/topic/2483-macintosh-plus-clone-on-pipistrello/#entry17269 Enjoy! Magnus
  21. I have been working on porting the Plus Too code from Big Mess o' Wires to Pipistrello. This code base have been dormant for a while but recently the folks at MiST picked it up and added more features like keyboard and sound support etc. This is definitely work in progress but I got it to boot to the desktop with working mouse, keyboard and sound. The image data for the 400 K system disk is stored in flash memory after the bit file and is transferred to RAM at boot time. Video is via DVI. The project uses the 1 MB Oberon wing that provides 1 MB of static RAM and PS/2 connectors for mouse and keyboard. Here is a short video of it booting: http://www.saanlima.com/images/boot.mov And keyboard input: http://www.saanlima.com/images/kbd.mov Links: Big Mess o' Wires: http://www.bigmessowires.com/category/plustoo/ MiST PlusToo forum: http://atari-forum.com/viewtopic.php?f=101&t=28648 More to come... Magnus
  22. xapp808 is creating an embedded microblaze system using EDK (Embedded Development Kit) which is NOT part of the free ISE webkit license. A stand-alone ISE EDK license is about $500. Also, the embedded system needs some kind of RAM to use for microblaze code so you would need a board with external RAM like Papilio Duo or Paplio Pro. Magnus Edit: link to EDK product page: http://www.xilinx.com/tools/platform.htm
  23. Jack, I think you have the channel A/B swapped in your explanation above. FT2232D only has an MPSSE engine on channel A. From the FT2232D data sheet: 8.5 Multi-Protocol Synchronous Serial Engine (MPSSE) Mode Signal Descriptions and Interface Configurations MPSSE Mode is designed to allow the FT2232D to interface efficiently with synchronous serial protocols such as JTAG and SPI Bus. It can also be used to program SRAM based FPGA‟s over USB. The MPSSE interface is designed to be flexible so that it can be configured to allow any synchronous serial protocol (industry standard or proprietary) to be interfaced to the FT2232D. MPSSE is available on channel A only. MPSSE is fully configurable, and is programmed by sending commands down the data pipe. These can be sent individually or more efficiently in packets. MPSSE is capable of a maximum sustained data rate of 5.6 Mega bits / s Magnus
  24. Flashrom can not program the flash chip on Papilio Pro since it expects the flash chip to be directly connected to the FTDI chip and use the MPSSE module in SPI mode. On Papilio Pro the flash chip is connected to the FPGA, not to the FT2232D device. The FT2232D device is connected to the FPGA JTAG port and the MPSSE module is used in JTAG mode. The only way to program the flash chip via the FT2232D is to first download a special bit file to the FPGA that translates JTAG commands to SPI transactions. This bit file is typically called bscan_spi_xxxx.bit where xxxx indicates which FPGA device this bit file is for. This is what the Papilio loader does (as well as other programmers like xc3sprog and fpgaprog). This instruction if for when you want to use the Papilio Pro as a stand-alone JTAG programmer for some other board. In this case the FPGA is held in reset to effectively disconnect it from the JTAG signals so they can control some other external device (like an ARM microcontroller or an AVR microcontroller) or program an external SPI flash chip. Again, you can not program the Papilio flash this way since it's not connected directly to the FT2232D. Hope this helps, Magnus Edit: Xilinx call this "Indirect programming" and talks about it in this document: http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/pim_c_introduction_indirect_programming.htm
  25. As an alternative to your pin headers, you could have used a ribbon cable with dip socket, like this one: http://www.digikey.com/product-detail/en/C2PXS-4006G/C2PXS-4006G-ND/1122835 Since it has 40 pins and your PCB has only room for a 36 pin ROM you would have to cut the four outer pins before solder it in. Magnus