• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by hamster

  1. Loading your own programs into block RAM there are many ways to load data into a block RAM. These can be broken down into two general categories - pre-synthisis or post-presynthisis. Assuming that you are going to place a compiled AVR project into the program memory of the AVR8 processor you will most probably want to use both at differnt times, as pre-systhisis is best suited for debugging test programs for the FPGA "hardware", where as post-systhisis is really convienient for implmenting new software revisions. Pre-synthesis This involves adding the required data into the FPGA source tree, and then building a new FPGA programming bitstream. Pros: Data is present in BRAM allowing source level simulation Easy to visualise and understand Cons: Long turnaround time, as a full rebuild is required to change RAM contents before configuring devices Data must be converted into a FPGA tool friendly format Data must be known at designtime A full FPGA development toolset is needed to update the BRAM contents If you use the VDHL 'GENERATE' contruct to create multiple BRAM blocks they will all have the same contents, limiting you to around 1k of code. Only really works with BRAMs who's width matches that of the target architecture. Putting data into an 8kx8bit memory out of eight 8kx1bit bit-planes isn't feasible. A new FPGA build is required for each different BRAM contents (in this case programs) Post-synthesis This involves updating the contents of the FPGA bitstram to contain the correct data in the correct location. Pros: All BRAM instances can have different contents Only a limited FPGA toolset is required to merge the new BRAM contents into the bitstream (the data2mem utility). Fast turnaround, as no project rebuild is required Can usually be integrated into the a software development toolchain (e.g. "makefile"). Can handle more complex memory configurations such as 'bit slices'. you build the hardware once and then merge many different programs quickly Cons: Can not be used with source level simulation, but can be used with device level simulation Far more complex to understand and implement How to update BRAM contents pre-synthesis The recipie for this is: Convert your '.hex' file to VDHL 'INIT_xx' attributes. In my Papillo build this is XPM8kx16.vhd Replace the existing 'INIT_xx' in the PM_INST instance in the AVR8 processor Rebuild the project Configure the device with the resulting bit file Note that the 'INIT_xx' parameters are interpeated like really large integers (32 byte integers) in LSB format. So if your wanted to have the following bytes in memory 0000: [tt] 0000: 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF [/tt] Your init string will be: [tt] INIT_00 => X"00000000000000000000000000000000FFEEDDCCBBAA99887766554433221100", [/tt] This doesn't make much sense until put in the context that BRAM blocks can have different widths. I've written a small 'C' program (available in the Papillo playground) which takes an Intel '.hex' file and outputs the lines to cut and past into the VDHL source. Another option (not useful in the context of the AVR8 processor) is to create a '.coe' file, which is used by the Block RAM generator wizard to set the inital values. A small example is: [tt] memory_initialization_radix=16; memory_initialization_vector=00,11,22,33,44,55,66,77,88,99,AA,BB,CC,DD,EE,FF; [/tt] If you do use a '.coe' file you will need to rebuild the BRAM IP and then the entire project after changing the file to include the updated data in your project. It is very long winded! How to update BRAM contents post-synthisis The recipie for this is: Convert your HEX file to a ".mem" file. Use the Xilinx "data2mem" program to insert the data in the '.mem' file into the '.bit' file. Configure the device with the resulting bit file. The merging process uses a "_bd.bmm" file define the "address space" created by one or more BRAM blocks. The BMM file for my AVR8 looks like: [tt] ADDRESS_MAP avrmap PPC405 0 0x00000000:0x00003FFF (16 KBytes). ADDRESS_SPACE rom_code RAMB16 [0x00000000:0x00003FFF] BUS_BLOCK avr_processor/PM_Inst/RAM_Inst[0].RAM_Word [15:0] PLACED = X1Y7; END_BUS_BLOCK; BUS_BLOCK avr_processor/PM_Inst/RAM_Inst[1].RAM_Word [15:0] PLACED = X1Y0; END_BUS_BLOCK; ... BUS_BLOCK avr_processor/PM_Inst/RAM_Inst[7].RAM_Word [15:0] PLACED = X1Y6; END_BUS_BLOCK; END_ADDRESS_SPACE; END_ADDRESS_MAP; [/tt] What first perplexed me was how to get the vaules for the "PLACED = XxYy" clause, but I discoved that the FPGA toolset does this for you. You first create a template "whatever.bmm" (e.g. "progmem.bmm") without the PLACED clauses, and during the Place & Route this gets updated and saved as "whatever_bd.bmm". Simple really once you know how it works. I've chosen to implement my merge as a windows CMD script, which copies in the ".hex" file from the project, then srec_cat converts it, and finally data2mem merges it with the FPGA bitstream: [tt] copy "c:AVR\vgatest\default\vgatest.hex" . srec_cat vgatest.hex -Intel --byte-swap 2 -Data_Only -Line_Length 105 -o vgatest.mem -vmem 8 C:\Xilinx\12.4\ISE_DS\ISE\bin\nt\data2mem -bm progmem_bd.bmm -bd vgatest.mem -bt avr8.bit -o b vgatest.bit [/tt] Due to unexpected behaviour in data2mem the ".mem" file needs to have an even number of bytes per line. A line length of "105" is enough to have 32 bytes on each line and matches nicely with the data in the '.hex' file. Debugging when things go wrong As with all things, debugging is the hard bit. The data2mem utility allows you to dump the contents of a bitstream, and you can then view it in a text editor. If you are lucky to be running on UNIX you can then use the 'diff' utility to compare the bitstream contents before and after the data2mem. As the AVR8 has an interrupt table at the start of memory it's regular structure is a great help. If you also use supply "_bd.bmm" file the BRAMs will be named with their instance names: [tt] C:\Xilinx\12.4\ISE_DS\ISE\bin\nt\data2mem -bm progmem_bd.bmm -bt avr8.bit -d [/tt] Gives me: [tt] ... BRAM data, Column 01, Row 07. Design instance "avr_processor/PM_Inst/RAM_Inst[0].RAM_Word". 00000000: 94 0C 00 30 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 ...0...R...R...R...R...R...R...R 00000020: 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 ...R...R...R...R...R...R...R...R ... [/tt] And there you have it! Hope it saves you a few days of banging you head against what feels like a brick wall.
  2. Ever thought of maintaining a map of Papilio's World Domination, and putting a red dot on when a n order ships? I know that at least a few exist here in New Zealand!
  3. hamster

    HDMI input

    I've been working on a HDMI input wing, and have hit what looks to be a potential major snag. The TMDS input requires 50 ohm termination resistors to 3.3V on the differential inputs, at a "suitable distance" from the FPGA's pin. I am assumed that the rising edge is around 0.5ns for a 750Mb/s 1280x720p signal. That gives a 1/4th Transition Electrical Length is about 2cm, and using my trusty scrap of paper the trace from the chip to the top of the wing connector is about 5cm. So I am now worried that if I locate the termination that far from the FPGA it will adversely affect the signal integrity. Can anybody confirm if this worry is well founded or not?
  4. hamster

    Issues with srec_cat.

    Hi Jack (and others). I've just been bashing my head against a problem - if I convert the AVR 'hex' file and put it in the VDHL for program memory it works, but when I merged the same hex file in with data2mem it didn't. I traced it down to srec_cat + data2mem giving different results depending on the length of the line in the lines in the '.mem' file generated by srec_cat. If the lines in the '.mem' file had 0xFF bytes it the second line merges in the wrong place (maybe due to byte swapping???). By using "srec_cat program.hex -Intel --byte-swap 2 -Data_Only -Line_Length 105 -o program.mem -vmem 8" the lines came out a convenient 32 bytes of date per line, and it merged in correctly. This was using srec_cat version 1.47.D001. Hope this helps somebody avoid the struggles I had. Cheers Mike. PS. Thanks for your efforts in porting the AVR8 to Xilinx - I am currently running this core on a Digilent Nexys2 - now that I have it up and running an order for a Papilio one will go in as soon as disposable income will allow!
  5. hamster


    That is like designing a rally car and asking if for best perfomance you should use racing slicks.... Let your engineers use whichever tool works for them - but it won't be C++!
  6. hamster


    WIth 100 boards you won't be at the point where the engineering costs for your own PCBs start making sense over an off-the-shelf board, unless you have other constraints that make it very important to you. If a off-the-shelf costs $1,500, it might have a build cost of about $500 per board, so you only get $100,000 for board development and tested before it isn't worth it financially, and that doesn't include any allowance for the risks and the development time. Given that you could pay a little more and get some fully-featured dev boards on your desk tomorrow that people can work with straight away, verses a complex PCB development, including the associated risk and expenses it seems a no-brainier. You always have the option of designing a custom board once things are up and running and your requirements have been are completely understood. I would think that it is a very limited skills pool - FPGA/ASIC, low latency designs, high speed comms, most likely gigabit networking , tcp/ip protocols, the understanding of the on-the-wire trading protocols, and then implementing HFT algorithms. The pool of people would be very small - about the same size as a niche medical specialist (e.g. in the same order as Orthopedic surgeons who specialize in jaw reconstructions). Defiantly not main-stream skills.
  7. hamster


    Hi oritemis.frc, I can give you an none-answer. We don't really have enough specs to give you a sensible answer. Say you wanted the top level of performance the entry price is pretty steep. If you wanted to accept multiple 10 Gbps fibers the hardware alone will cost something like $10k per instance. (http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,1328&Prod=NETFPGA-10G-SUME). If you only need multiple Gigabit interfaces the hardware is about $1.5k per board.. Tools to develop the application will cost $3k+ per year per seat. Any IP you license will also cost, like a wounded bull - for example a SATA IP block costs $20k per design. H/W cost is only a small bit. Engineering time will cost about $100k p.a. for an average VHDL engineer (see http://www.payscale.com/research/US/Skill=VHDL/Salary).Maybe $1k a day for a contractor. It would need a small team outside of the developers of main trading algorithm. - Software - embedded Linux will most likely be in there somewhere - A networking protocol engineer. - Programmable logic - maybe three engineers, or one really enthusiastic one. - Testing / Verification (e.g. making dummy feeds, testing benchmarking and so on. - Ongoing support. If you wanted to build custom boards you will need a high speed design engineer or two, and maybe $100k (if not more) for prototypes Development time frame really depends on system complexity - maybe 4 weeks, maybe 6 months. So as a rough budget. - hardware and setup for 5 engineers - maybe $100k. - Development resource (5 engineers for 6 months) - $8k per week per month per engineer = $240k - Office space, expenses, travel... - Contingency Call it $400k, on the back of an envelope, without actually knowning what you want to do.
  8. hamster

    Serial port issues

    Make sure you have software flow control turned off on the pprt , or you will lose all you XON/XOFF characters. (\x11 and \x13 IIRC) Mike
  9. An old trick is you can clock a BRAM with "not clk" and the result of a lookup is ready before the next rising clock edge... However your designs Fmax might halve so it isn't suited for high performance designs.
  10. hamster

    Papilio lock-in amplifier?

    Once you get it gojng, rather than using a sine wave, why not try a GPS gold code? ( or something similar to one) It is a pseudo random bit stream that is quite long. When you correlate with an external signal you can get a really precise phase lock. This time to phase lock is what gives the long time to first fix of a GPS as it trys all the different alignments, but once locked it is very solid, even though the power levels of the signal is well below the noise floor and mixed up with all the other GPS birds. By having g a real time clock on the GPS the time to first fix is improved as the GPS knows where to start hunting. Also, I believe that most GPS units have a one bit DAC, so maybe a bandpass filter and to compare against the long term average is all you need?
  11. If you want to listen to an hour's banter about FPGAs, have a listen to this week's Amp Hour podcast. http://www.theamphour.com/237-an-interview-with-joe-and-mark-garrison-subtly-spelling-sayleeay/ It's a great interview with the guys behind the Saleae Logic Analysers.
  12. Hi, Somebody was after a way to send the input state of pins through to a host/PC for logging, so I knocked something up from them. http://hamsterworks.co.nz/mediawiki/index.php/Log_Pins It logs 11 pins as an ASCII string of ones and zeros, followed by a NL and CR, at 9600 baud on the virtual serial port. It only sends an update when the state of the input changes. Somebody might also be able to make use of it as a debugging interface...
  13. hamster

    Newbie on Mojo V3

    You may also want to break it down into smaller chunks, that you can put together into a working project. First start with turning on some LEDs, then.... a: Can you receive a single byte from the PC and display it on some LEDs? b: Can you generate a VGA test picture? c: Can you make a memory and play back a pattern onto LEDs? Then you can build a+b: Can you store bytes from the PC into a memory? b+c: Can you display a picture from memory? Then finally a+b+c: Taking data from the host, storing it in memory, and displaying it on the screen.
  14. If you have an passing interest in DSP or Software defined radio, then you simply have to watch this talk. It starts off pretty weak for a minute or so , but once the presenter gets going...
  15. hamster

    External RAM

    GBs might be expecting a bit much. Here's an example part for you http://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en559112 It has some funny 2-data-pin DDR mode, where you can get 10MB/s out of it. Not too shabby.
  16. hamster

    External RAM

    Possibly? Yes. Practical? No. The speed of signals needed to operate a SDRAM chip property make this impractical. If you were to run you serial interface at 100MHz, and used ram with a 16 bit data bus the SDRAM chip would be clocked at about 6MHz. There are however static RAM chips with a serial interface that could be used, that require only three or four wires.
  17. You can do this - http://forum.gadgetfactory.net/index.php?/page/articles.html/_/papilio/logicstart-megawing/using-just-the-switches-and-leds-on-the-logicst-r56 - and then you have 16 spare I/O pins where you can connect up more switches and LEDs using jumper wires (or Button wings).
  18. Here is how to drive a low-cost stepper motor and to count the steps taken. The motor used was low cost - only US$7 with the driver board! http://hamsterworks.co.nz/mediawiki/index.php/Stepper
  19. I've been thinking about this while mowing the lawns. The output of the piezo will have really high impedance, as is the ADC's input impedance. You might just get away with this (ignore the part names, ADC inputs are on the right): The Rs should be around quite high value - maybe 1M or above, and the diodes are to clamp the input just in case the input goes outside of the power supply range. Just try it without the low-pass filter cap first, and then experiment to find a suitable value - it should be around 0.47n or so to get a -3db filter of around 600Hz or so, assuming you use 1M ohm and the piezo output impedance is higher than than. Oh, and because of the high impedance, using an oscilloscope to watch what is going on will not give accurate readings. EDIT: The ADC's AC input impedance is about 100 ohms, so maybe some sort of buffer will be needed, esp for high sample rates.
  20. The ADC is 0-5v IIRC so if you use a rail to rail op-amp powered by 5v then there is no way that it could exceed the input range. One thing I just thought of is that the low pass filter is drawn to use a. Opamp with a +/- ?V supply, not 5v / 0V. I will sketch something up later tonight
  21. This is a low pass filter from http://www.electronics-tutorials.ws/filter/filter_5.html. It has a -3db cutoff filter at 159 Hz, give or take. (note - the power connections for the OpAmp are not shown!) Were the C value reduced, the cutoff frequency would rise - a 33nF cap would give you about 472 Hz (about what I guess you may want), If you were to sample the resulting signal at about 5kHz, you should have no problem with aliases. However, I don't know the output impedance of a piezo disk pickup, it might be far higher than this circuit needs. If things don't work well you might need a JFET buffer to match the two together. (from http://www.muzique.com/lab/splitter.htm)
  22. When a Papilio Duo is connected using both MicroUSB and MiniUSB,cables how many virtual COM ports will I expect to see? Will it be one for the Arduino interface and one for the FPGA? Or is the Arduino interface hidden behind the FPGA, and a bit file is required to make the connections for programming - much like how the EEPROM is accessed on the PapOne and PapPro. Mike
  23. I've just finished testing my LED driver PCB - 8 channels, each driving two constant current outputs (well, sinks actually). Loaded with 50 ohm sense resistors it gives 13mA per channel. 33 ohm will give 20mA. It is using discrete transistors to allow for higher power dissipation - maybe up to 300mW per channel, so should survive a hard short in in LED chains that that run at up to 15V. If anybody wants a PCB just ask... I can send it air post so you might just be able to use it for your Christmas tree lights
  24. I like it :-) For the electronics guys, I also like the "Have you ever played around with solderless breadboards and little ICs? - and FPGA is equivilent to a breadboard the size of a somewhere between a garage and a basketball court, all covered in digital ICs, and a thousand eager minions ready to do the tedious wiring for you".
  25. I've put in feelers to talk at the OSHW miniconf in Auckland NZ early next year.(see https://linux.conf.au/media/news/58) I am starting to think that a name change could be beneficial to OSHW on FPGA. Perhaps if we were to redefine FPGAs as "Software Defined Hardware" it would sound more alluring and marketable. What you you think? Mike .