Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Apr 12, 12:12=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > On Apr 12, 6:49=A0am, Chris Higgs <chiggs...@googlemail.com> wrote: > > > On Apr 9, 9:05=A0pm, Patrick Maupin <pmau...@gmail.com> wrote: > > > I fail to understand why people don't code testbenches in a nice > > dynamic language like python. > > Because it's just as productive to code models and deal with only one > language. > > > Limit the use of HDLs to describing the hardware and make use of a > > high-level scripting language to read in files/generate stimuli, check > > results and introduce errors/modify state dynamically. It's time to > > move on from the immensely limited HDL fileIO testbench model. > > Perhaps you should adjust your mindset and consider that testbench > models are in no way limited to 'fileIO testbench models'. > Testbenches can use real models of real devices, it's not that hard. > Error injection handled easily as well. =A0'High level' scripting > languages don't necessarily have any inherent advantages, they're just > different languages. > > KJ The way most people* tend to write testbenches is to use a scripting language to generate stimuli file and check the results (also written to a file) afterwards. That's fine if you're doing some pipelined transformation function where no re-ordering or dropping of data can occur, but falls down with less rigid designs. The point is that HDLs aren't well suited for writing complex testbenches. Yes, many things are possible but in practice they are clunky and tend to balloon into a mess. I've seen far too many unmaintained, overly complicated and indecipherable testbenches written in HDLs. I've seen a several thousand line VHDL package to generate ethernet frames. In python its as simple as "from scapy.all import Ether; pkt=3DEther()". 'High level' scripting languages have many inherent advantages. For example - I'm currently testing an "ethernet switch" like device. It's behaviour depends on various dynamic configuration options and internal state (fill levels etc). Try writing a testbench for that in VHDL - it would take forever! Using python, I can generate packets using an existing library, directly read (and modify) the internal state, use the state to determine the correct actions for each packet (not possible in an HDL testbench without artificially bringing signals out of the top level). I can also use the exact same software written to configure and control the programmed FPGA in hardware to control the unit under test in the testbench, widening the scope of the test coverage. The biggest advantage, however, is the speed with which I can write complex tests. *Obviously this is all in my own humble opinion and limited experience. I'd be interested to hear alternative approaches to testing that people use. I just happen to be strongly prejudiced and believe many people would benefit from adopting approaches more similar to my own ;) Thanks, ChrisArticle: 147051
On Apr 9, 6:57=A0pm, "vragukumar" <vragukumar@n_o_s_p_a_m.n_o_s_p_a_m.signalogic.com> wrote: > Hello, > > We are trying to determine the number of slices that a specific module in > the design consumes upon synthesis. Is there a way to generate a report > that shows resource utilization per module using Xilinx ISE Webpack v11.5 > ? > > Thanks and Regards, > Vikram. =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com I can't speak for post synthesis resource utilization since I don't use ISE for synthesis. But for post map, the .mrp file produced by map has the info you are looking for (look for a big table at the end of the file). ChrisArticle: 147052
Can anyone recommend a cross beween reading material and reference material for MPEG coding? I am familiar with JPEG, and the JFIF file structure and would like to know more about MPEG, preferably to include MPEG-4 with a view to coding MPEG4 streams.Article: 147053
On Apr 1, 12:04=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Mar 31, 1:51=A0am, luudee <rudolf.usselm...@gmail.com> wrote: > > > Does anybody else, besides xilinx, make FMC boards for ml605 & sp605 ? > > > HW-FMC-XM105-G =A0FMC XM105 DEBUG CARD > > HW-FMC-XM104-G =A0FMC CONNECTIVITY MEZZANINE CARD > > > Buying Xilinx products now means going through Avnet, which is a > > nightmare and HUGE lead times ... > > > Thanks, > > rudi > > While the XM104 is listed with a 8 week lead time on the Avnet site, I > know that we have these available in inventory and they will ship > promptly after the order is placed. =A0The XM105 is listed with a 2 week > lead time. > > There are a number of other companies releasing FMC cards, just be > sure that the cards support a VADJ of 2.5V and there shouldn't be a > problem. > > 4DSP recently announced a FMC familyhttp://www.przoom.com/news/66794/ > > Curtiss-Wright also has a number of boards.http://www.cwcembedded.com/0/6= 2/651.html > > And Xilinx has a number of other boards in pipeline to be released > next quarter.http://www.xilinx.com/fmc > > Ed McGettigan > -- > Xilinx Inc. Ed, just an update ... I ordered the above two boards through Avnet on April 1st. As of today (April 12th), they are still listed as on "back order" with 2 & 8 week lead times. Is there an alternative way to buy these boards ? We are an alliance partner if makes any difference ... Thanks, rudi@i_hate_avnet.suckArticle: 147054
On 09/04/2010 21:31, Nico Coesel wrote: > rickman<gnuarm@gmail.com> wrote: > >> I think I have about had it with VHDL. I've been using the >> numeric_std library and eventually learned how to get around the >> issues created by strong typing although it can be very arcane at >> times. I have read about a few suggestions people are making to help >> with some aspects of the language, like a selection operator like >> Verilog has. But it just seems like I am always fighting some aspect >> of the VHDL language. >> >> I guess part of my frustration is that I have yet to see where strong >> typing has made a real difference in my work... at least an > > I also write a lot of C. Over the past years I've noticed that C > compilers (GCC to be exact) have become much more strict when it comes > to type checking. No more automatic casting. I'm sure this is done for > a good reason! > It's not correct that C compilers have become stricter about type checking - a standards-conforming C compiler has to support exactly the same automatic typecasting as always. However, gcc's warning capabilities have improved enormously over the years (it's better than any other C compiler I have used), and if you enable those warnings it will tell you about potential problems with losing bits on casts, mixing signed and unsigned data, etc. It still has to accept it as valid C, however (unless you use the option to make warnings act as errors). Compiling in C++ mode gives you a little bit extra type strength - for example, enumerations become proper types.Article: 147055
On 11/04/2010 01:06, -jg wrote: > On Apr 10, 2:07 am, rickman<gnu...@gmail.com> wrote: >> One of my goals over the summer is to teach myself Verilog so that I >> can use it as well as I currently use VHDL. Then I can make a fully >> informed decision about which I will continue to use. I'd appreciate >> pointers on good references, web or printed. > > You could also look at Jan Decaluwe's MyHDL ? > > http://www.myhdl.org/doku.php > > and a case example here : > > http://www.jandecaluwe.com/hdldesign/digmac.html > > this allows you to go in either direction, to VHDL to Verilog, and to > 'test early'. > That occurred to me too. FPGA design is not limited to VHDL or Verilog - there are many other options. One of the challenges is finding a tool that has strong enough support to be around for the future. Many years ago I did some FPGA (and CPLD) work using confluence - I found it much easier to write compact and correct code with confluence than with VHDL or Verilog. But the tool's author dropped development to work on other projects (fair enough, I suppose - he never claimed confluence to be anything other than free development software). Although it was open source, it didn't have a strong enough community to survive. MyHDL, on the other hand, has been around for many years, and has a reasonable-sized community. It is definitely worth looking at if you are not happy with Verilog or VHDL.Article: 147056
On Apr 12, 5:49=A0am, Chris Higgs <chiggs...@googlemail.com> wrote: > I fail to understand why people don't code testbenches in a nice > dynamic language like python. Well, I do. But for really basic stuff, I use Verilog.Article: 147057
e. > >MyHDL, on the other hand, has been around for many years, and has a >reasonable-sized community. It is definitely worth looking at if you >are not happy with Verilog or VHDL. > > I don't believe there is any risk in trying/using MyHDL for the following reasons. 1. It is stable and has been used for many FPGA and an ASIC project. 2. It is open-source. 3. The output is Verilog/VHDL, you can go back to an old flow if desired. The 3rd might not seem reasonable to some because it is computer generated HDL but it is not computer generated HDL like most think. It is simply a translation from one RTL language to another RTL language (MyHDL -> Verilog/VHDL). The structure will be the same just some minor name adjustments. chris --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147058
On Apr 12, 4:23=A0am, Jan Decaluwe <jandecal...@gmail.com> wrote: > On Apr 11, 5:03=A0am, Patrick Maupin <pmau...@gmail.com> wrote: > > > So, no, I don't think I'm confused at all (I can't speak for my > > readers; I often leave those confused, I'm sure) and I stand by my > > assertion that one of the key principles of programming in Python is > > that typing errors are typically the least of the possible errors in a > > real program. > > As a thought experiment, imagine a Verilog revision based on a > pythonic mindset. Here's what would likely happen to Jonathan's > examples: > > Issue: Most-significant bits silently lost when you copy a > wide vector into a narrow one. > New behavior: run-time or compile-time error. > Rationale: "Errors should never pass silently". (Python zen) I agree that this particular issue would better be served by an error, but, in point of fact, all the synthesizers and simulators and lint checkers I use allow you to treat this as an error if you so choose. > Issue: Signed values silently zero-filled to the width of a > wider target. > New behavior: Use sign bit extension instead. > Rationale: Obvious language design errors should be fixed. Again, this is a nice to have, already covered by the tools. And even in Python, there are few, in retrospect, "obvious language design errors" that were not fixed until 3.0, because breaking backward compatibility is a huge problem. > Verilog > designers are surprizingly tolerant to those, but a Python language > designer would never get away with this. It is certainly believable that if an HDL were designed by Guido, it wouldn't have these particular issues. However, these errors you describe are relatively inconsequential, in that even the most rudimentary of testbenches would catch them, and IMO the mindset of both good Python programmers and good RTL programmers is that testbenches are de rigueur. > As a conclusion, your reference to Python to justify Verilog's > current behavior is rather unconvincing. I'm not justifying its behavior per se, just pointing out that none of the good Python programmers I have worked with would have any problem getting Verilog up and running. And I will categorically state that, despite its flaws, the design of the Verilog language is much closer to Python than the design of VHDL is. Regards, PatArticle: 147059
Greetings, The synthesis report on my design tells me that I have caused 3 latches to be created: 1 LDC and 2 LDP. I didn't intend to create any... Rather frustratingly, the reports aren't telling me which signals are associated with these latches, so that I can fix my code! My colleagues can't remember what the trick is. Please can someone enlighten me? Thanks in advance, R. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147060
> > How comfortable are you with most-significant bits being > silently lost when you copy a wide vector into a narrow > one? =A0How about signed values being silently zero-filled > to the width of a wider target? > I always ran into this problem at my old employer as there wasn't strict enforcement of coding guidelines. But I never tripped on it in a messy way because the tools always caught the problem as a warning (not an error). And they were pretty consistent about it. One aspect of the learning the language I found quite useful was that I thought of coding with the language as if I was drawing a schematic with it. I filtered all the new knowledge about the language through this fundamental premise. Here Palnitkar's book really helped me. Ofcourse at that time verilog 2001 was just getting a lot of attention.Article: 147061
On 4/12/2010 5:14 PM, RCIngham wrote: > Greetings, > > The synthesis report on my design tells me that I have caused 3 latches to > be created: 1 LDC and 2 LDP. I didn't intend to create any... > > Rather frustratingly, the reports aren't telling me which signals are > associated with these latches, so that I can fix my code! My colleagues > can't remember what the trick is. Please can someone enlighten me? > > Thanks in advance, > R. > Search through the EDIF file? HTH, Syms.Article: 147062
>On 4/12/2010 5:14 PM, RCIngham wrote: >> Greetings, >> >> The synthesis report on my design tells me that I have caused 3 latches to >> be created: 1 LDC and 2 LDP. I didn't intend to create any... >> >> Rather frustratingly, the reports aren't telling me which signals are >> associated with these latches, so that I can fix my code! My colleagues >> can't remember what the trick is. Please can someone enlighten me? >> >> Thanks in advance, >> R. >> > >Search through the EDIF file? > >HTH, Syms. > What EDIF file? Or perhaps, which EDIF file? And don't suggest the post-Synthesis gate-level netlist, either. Been through that and failed to find and LD* components... --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147063
I am working with a Virtex-5 FPGA PCIe-based board and want to create three interfaces (lanes?). One that is a two way serial interface running at 1 MHz. Another running at 1 MHz but only input to the board. The last interface or lane will be 16 bit input only running at 28 MHz. I am reviewing the Avnet Development Kit User Guide for the board and have the Integrated Endpoint Block for PCI Express Designs document. I suspect all the answers how to configure the board are in those documents but since I have never done this before, I don't know where to start. Also, the FPGA code will be taken from another system that has a 1 MHz serial I/O, 1 MHz serial input-only, and a 28 MHz 16 bit parallel, input-only custom interfaces. The PCIe bus in this case will emulate those three. Any suggestions from anyone with more experience? I really appreciate anything I can get about this. Thanks, EricArticle: 147064
On 12 Apr, 12:44, Chris Higgs <chiggs...@googlemail.com> wrote: > Using python, I can generate packets using an existing library, > directly read (and modify) the internal state, use the state to > determine the correct actions for each packet (not possible in an HDL > testbench without artificially bringing signals out of the top level). > I can also use the exact same software written to configure and > control the programmed FPGA in hardware to control the unit under test > in the testbench, widening the scope of the test coverage. The biggest > advantage, however, is the speed with which I can write complex tests. > > *Obviously this is all in my own humble opinion and limited > experience. I'd be interested to hear alternative approaches to > testing that people use. I just happen to be strongly prejudiced and > believe many people would benefit from adopting approaches more > similar to my own ;) Are you using Python to test VHDL or Verilog HDL? Which simulator are you using? I know of MyHDL, but if I could use Python to test my VHDL that would be interesting :-), particularly if I can use it to build my FPGA design too. For the later I'm currently use Tcl.Article: 147065
On Apr 12, 7:44=A0am, Chris Higgs <chiggs...@googlemail.com> wrote: > > The way most people* tend to write testbenches is to use a scripting > language to generate stimuli file and check the results (also written > to a file) afterwards. I have no idea whether or not "most people" test as you say or not...I will say that I must not hang around with those folks though since my crowd writes self checking testbenches. I do use file I/O for some stimulus/response, but is more along the lines of something like - Reading in a .BMP file (JPG, TIFF, etc.) to model an image that is an input to the system - Writing out those types of files as well as CSV files of various transactions to use aid debug to find out what went wrong when the testbench hits an assertion. > The point is that HDLs > aren't well suited for writing complex testbenches. Maybe...that is until you've got the packages written to support all these nice things. But once you do have those packages, you don't rewrite them in order to use them on the next project. > > 'High level' scripting languages have many inherent advantages. For > example - I'm currently testing an "ethernet switch" like device. It's > behaviour depends on various dynamic configuration options and > internal state (fill levels etc). Try writing a testbench for that in > VHDL - it would take forever! > I can't comment on your specific case, but I don't find writing models for things to be that difficult...in fact it is rather liberating since I'm free of the shackles of 'synthesizable' code. > Using python, I can generate packets using an existing library, > directly read (and modify) the internal state, use the state to > determine the correct actions for each packet (not possible in an HDL > testbench without artificially bringing signals out of the top level). Not sure why you say it's not possible. I've yet to bring signals out of the top level for simulation test purposes...on rare occasion I have cheated a bit by having a 'magic comms' package but by and large, the system testbench ferrets everything out based on the actual simulation behavior without having any cheats. > I can also use the exact same software written to configure and > control the programmed FPGA in hardware to control the unit under test > in the testbench, widening the scope of the test coverage. The biggest > advantage, however, is the speed with which I can write complex tests. > That's a good advantage to have too. Kevin JenningsArticle: 147066
Thorsten Kiefer <info@tokis-edv-service.de> writes: > I contacted the author. He says that the copyright is owned by the > publisher, not by himself. And the publisher denies publishing that code. Do you think you could maybe mention what book and where in it the missing code can be found? You should include the UCF file too.Article: 147067
>Are you using Python to test VHDL or Verilog HDL? Which simulator are >you using? I know of MyHDL, but if I could use Python to test my VHDL >that would be interesting :-), particularly if I can use it to build >my FPGA design too. For the later I'm currently use Tcl. > > My guess would be which ever Python to HDL simulation method you use there would be some learning curve for the interface. With MyHDL there is very little you need to learn to write your testbenches. Most everything can be accomplished with basic Python. Also, the MyHDL group is very helpful if you need assistance or run into trouble. Even if you are only interested in writing testbenches in MyHDL I believe it is straight forward and it provides you all the tools of Python. There are scripts available to run/control the FPGA tools from Python. Mainly consists of executing the correct cli commands. MyHDL support Icarus and Cver open-source Verilog simulators and has been used with commercial simulators such as ModelSim. chris --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147068
>There are scripts available to run/control the FPGA tools from Python. >Mainly consists of executing the correct cli commands. > Should say, Python scripts are available on the web, not part of MyHDL, for controlling the various vendors tools. chris --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147069
On Apr 12, 12:47=A0pm, Eric Chomko <pne.cho...@comcast.net> wrote: > I am working with a Virtex-5 FPGA PCIe-based board and want to create > three interfaces (lanes?). =A0One that is a two way serial interface > running at 1 MHz. =A0Another running at 1 MHz but only input to the > board. =A0The last interface or lane will be 16 bit input only running > at 28 MHz. =A0 <snip> From the sounds of your post, I think your best bet would be to first start be getting a better handle on PCIe and how it works in general. Spending a few days reading through Mindshare's PCIe System Architecture book will probably help explain the general topology of PCIe. Once the fundamentals of PCIe are understood, it will make mapping these to an FPGA implementation much easier. Here is Amazon's link to the book: http://www.amazon.com/Express-System-Architecture-Mindshare-Inc/dp/03211563= 07 The Mindshare books are a goldmine, IMHO. Good luck, JohnArticle: 147070
On 12 Apr., 18:59, "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > >On 4/12/2010 5:14 PM, RCIngham wrote: > >> Greetings, > > >> The synthesis report on my design tells me that I have caused 3 latche= s > to > >> be created: 1 LDC and 2 LDP. I didn't intend to create any... > > >> Rather frustratingly, the reports aren't telling me which signals are > >> associated with these latches, so that I can fix my code! My colleague= s > >> can't remember what the trick is. Please can someone enlighten me? > > >> Thanks in advance, > >> R. > > >Search through the EDIF file? > > >HTH, Syms. > > What EDIF file? Or perhaps, which EDIF file? > And don't suggest the post-Synthesis gate-level netlist, either. Been > through that and failed to find and LD* components... > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Hi, the synthesis report tells you at least in which module of your design the latch is found. The reasons are mostly cases without when others and ifs withut else in combinatorical processes. (or conditional assignments outside of processes) These should be easy to identify. You shouldn't have too many combinatorical processes anyway. Have a nice synthesis EilertArticle: 147071
On 10 Apr., 00:57, "vragukumar" <vragukumar@n_o_s_p_a_m.n_o_s_p_a_m.signalogic.com> wrote: > Hello, > > We are trying to determine the number of slices that a specific module in > the design consumes upon synthesis. Is there a way to generate a report > that shows resource utilization per module using Xilinx ISE Webpack v11.5 > ? > > Thanks and Regards, > Vikram. =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com I don't think that ISE gives you that sort of report, Synplify Pro does, though!Article: 147072
If your design is not to vendor specific you can try QNS to see what it comes back with, Hans www.ht-lab.com "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote in message news:rv-dnR4A5Kl5217WnZ2dnUVZ_qednZ2d@giganews.com... > Greetings, > > The synthesis report on my design tells me that I have caused 3 latches to > be created: 1 LDC and 2 LDP. I didn't intend to create any... > > Rather frustratingly, the reports aren't telling me which signals are > associated with these latches, so that I can fix my code! My colleagues > can't remember what the trick is. Please can someone enlighten me? > > Thanks in advance, > R. > > > --------------------------------------- > Posted through http://www.FPGARelated.comArticle: 147073
>On 12 Apr., 18:59, "RCIngham" ><robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: >> >On 4/12/2010 5:14 PM, RCIngham wrote: >> >> Greetings, >> >> >> The synthesis report on my design tells me that I have caused 3 latche= >s >> to >> >> be created: 1 LDC and 2 LDP. I didn't intend to create any... >> >> >> Rather frustratingly, the reports aren't telling me which signals are >> >> associated with these latches, so that I can fix my code! My colleague= >s >> >> can't remember what the trick is. Please can someone enlighten me? >> >> >> Thanks in advance, >> >> R. >> >> >Search through the EDIF file? >> >> >HTH, Syms. >> >> What EDIF file? Or perhaps, which EDIF file? >> And don't suggest the post-Synthesis gate-level netlist, either. Been >> through that and failed to find and LD* components... >> >> --------------------------------------- =A0 =A0 =A0 =A0 >> Posted throughhttp://www.FPGARelated.com > >Hi, >the synthesis report tells you at least in which module of your design >the latch is found. >The reasons are mostly cases without when others and ifs withut else >in combinatorical processes. >(or conditional assignments outside of processes) > >These should be easy to identify. >You shouldn't have too many combinatorical processes anyway. > >Have a nice synthesis > Eilert > I've been through the .SYR file several times, and there is no such report. Is there a missing command switch in the script? Perhaps they are in the .NGC file relating to the MicroBlaze processor. As this is a reused item, why were they not spotted before? I'll try to synthesize some of the blocks separately... Grrrr! --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147074
RCIngham wrote: > Perhaps they are in the .NGC file relating to the MicroBlaze processor. As > this is a reused item, why were they not spotted before? I'll try to > synthesize some of the blocks separately... I think that I have read somewhere (where ? from another thread on latch inference ?) that the Microblaze core uses a few latches. So this could be a valid theory. You could test it by replacing your MB core with a dumb one, and see if the latches are still there. > Grrrr! don't worry... it wouldn't change anything. yg -- http://ygdes.com / http://yasep.org
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z