System design in FPGA
in [FPGA]
|
Prev: Call for Papers: The 2010 International Conference on Wireless Networks (ICWN'10), USA, July 2010
Next: how to read bmp file in vhdl
From: Thomas Stanka on 21 Feb 2010 04:08 > Someone pointed out using using records to transfer signals from one > entity to another. While this is a good idea, will synthesis tools > like Xilinx accept a record of STD_LOGIC or STD_LOGIC_VECTOR in the > description of an entity? Each serious synthesis tool accepts records. Unfortunately some of the common used tools tend to replace a record by a vector after synthesis which makes debugging in netlist simulation a pain. Better tools synthesis to names like record.entry1 and record.entry2. bye Thomas
From: Martin Thompson on 22 Feb 2010 05:00 jozamm <jozamm(a)gmail.com> writes: > Hi all, > > I am a budding FPGA designer and I am in the process of designing > first system. Until now I have partitioned my system into various > entities, each entity implementing a small part of the system. It is > also easier for implementation. However I have found myself in routing > a lot of signals from one entity to another which increases complexity > in a way. > As others have noted, deciding where to draw the boundaries is a bit of an art. In terms of routing signals around, records can help with that: if you want to push an extra signal down the hierarchy, you just add it to the appropriate record and recompile. However, make sure you package things together sensibly - by function is often good. Not just "all the signals to this entity go in one record" as then you can end up with all the signals in the design in one big record! Splitting things down into "things that are easy to test" is a good boundary in my experience. Here's an example - say you want an image processing system which does an "edge detecting" function, then does a "peak detecting" function on the results of that and then a "assign x,y coordinates to each peak we detected" function. You could stick all of that into one big block of code, but when you get the wrong x coordinates out of the far end, you have no idea which subfunction went wrong. Instead you design three blocks, one for each of the functions, and test them individually. You can get each part right *in isolation*. Then when you wire them all together and test it, and it doesn't work first time (!), you only have to look at the higher-level integration to see what's wrong. It may sound like more work this way (writing testbenches doesn't feel like productive work, especially when you're starting out). But once you get proficient (which means practicing, just like playing your scles on the piano :), you can do the testing very quickly because each individual test is fairly simple. And you can push your design to all the corner cases, which is much more difficult when testing the whole thing all together. Cheers, Martin -- martin.j.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
From: Nial Stewart on 22 Feb 2010 07:56 Most of what's been posted is good advice. I usually split design into functional blocks which can then be indepentantly functionally tested, these are my entities. When it comes to signal routing I had to pick up a design a while ago that used records all over the place. I found this obscured the functional intent and made it much more difficult to debug so I'm not a big fan, although I have used them in a couple of instances. Keep it all as simple as possible! Nial.
From: Benjamin Couillard on 22 Feb 2010 15:05 On 22 fév, 07:56, "Nial Stewart" <nial*REMOVE_TH...(a)nialstewartdevelopments.co.uk> wrote: > Most of what's been posted is good advice. > > I usually split design into functional blocks which can then > be indepentantly functionally tested, these are my entities. > > When it comes to signal routing I had to pick up a design a while > ago that used records all over the place. I found this obscured the > functional intent and made it much more difficult to debug so I'm not > a big fan, although I have used them in a couple of instances. > > Keep it all as simple as possible! > > Nial. I think that records that group "related logic" make design clearer. The important thing is not to group random signals in a record. For example, I use records to interface my sdram controller with my other processing blocks. One record is called "sdram_if_input_t" for the sdram controller interface inputs and the other one "sdram_if_output_t" for the controller outputs. Therefore my block called "video_processing" is connected by 2 signals to the sdram controller instead of being connected by 10-15 signals to the sdram controller. That way the top level is much much clearer since the number of signals is reduced. The possibility of errors is reduced too because there's less risk of connecting the wrong signal in the wrong place with records. For entities, I think that if you have trouble saying what is the purpose of the block you're designing, then your block is probably doing too much or not enough. That's what I aim for. That way it's easier to reuse the block and the testbench design is also easier. I also try to use only one process for my entities when possible (After looking at Mike Treseler's code). Benjamin
From: Andy on 22 Feb 2010 15:48
On Feb 20, 10:24 am, Petter Gustad <newsmailco...(a)gustad.com> wrote: > Or interfaces if you're using SystemVerilog. Interfaces can carry > signals which run in both directions. VHDL records can only carry > signals running in a single direction. A record port can only have a single mode, but it can be inout. multi- directioned records require resolved types and default drivers defined everywhere those elements are used only as inputs. It requires a lot of work down below, but at the top level, plumbing is sweet easy to maintain. Need another signal? Just add it to the record type and to the default undriven value constant, then you only need to patch it in where it is ultimately used. User defined collections of per-element modes for records has been on my Christmas list for a long time... Andy |