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 7 Aug 2006 23:40:14 -0700, fpga_toys@yahoo.com wrote: >in binary. Because of the extensive timing and instantiation control in >the languages, the VHDL/Verilog synthesis tools are obligated to >implement the circuits as described ... and this will forever be a >handy cap. > >With higher level languages, which avoid specific details about the >instantiation, then the compiler becomes free to choose whatever >hardware that will produce the described results, and optimize out >everything else that doesn't matter. Vhdl/Verilog really lack that >freedom, when the design description is as precise as what clock edge, >and what logic level, every object is at. Actually, you can make your VHDL or Verilog description much more abstract than this. I've recently been working with some very abstract VHDL code, some of which was untimed, and some of which used functions and procedures rather than explicit hierarchy. It was also very dependent on passing around large records, and letting the synthesiser get rid of the unused bits. The untimed code relied on register retiming in DC (which I think XST supports). Personally, I really hate this sort of code. It was synthesising to about 75 logic levels between clocks before I started hacking it. >That is not a reasonable vision, while the >only tools to program fpga designs, and at the bit and clock edge >level. Give it a go - try some abstract code on your favourite synthesiser. DC has a 'map_to_entity' pragma which allows you to write a behavioural function or procedure for simulation, and map it to an entity for synthesis. I tried running some example code that uses this pragma through Amplify recently, and it ignored the pragma, and synthesised the behavioural code correctly. Synplify would probably do exactly the same. >I'm actually looking foward to a SystemC tool based >on C++ sematics that has really good synthesis ... maybe a few years >from now? It'll never happen; already been tried, failed. Hacking low-level hardware semantics into existing C++ semantics just gives you a verbose and complex mess, which is nowhere near as concise and clear as a VHDL or Verilog description. Great for modelling, non-starter for real-world synthesis. BTW, I google'd FpgaC and spent 10 minutes looking at the SourceForge site, before giving up. There's no obvious overview, FAQ, or documentation; you'll need to fix this if you want to get anyone interested. Unrelated to your comments, but a couple of people elsewhere in this thread were comparing Verilog to C. I guess I've missed this - I've spent many years writing C, C++, and Verilog, and I've never noticed *any* similarity between Verilog and C, apart from the most superficial. I'd really like to see someone produce a list of these similarities. EvanArticle: 106126
"Evan Lavelle" <eml@nospam.uk> wrote in message
news:n6kgd2hns1l37ftdjuh8u1nnq6a294m6i5@4ax.com...
> On 7 Aug 2006 23:40:14 -0700, fpga_toys@yahoo.com wrote:
>
> Unrelated to your comments, but a couple of people elsewhere in this
> thread were comparing Verilog to C. I guess I've missed this - I've
> spent many years writing C, C++, and Verilog, and I've never noticed
> *any* similarity between Verilog and C, apart from the most
> superficial. I'd really like to see someone produce a list of these
> similarities.
In summary: &&, ||, !, &, |, ^, ~, ==, !=. :-)
-Ben-
Article: 106127On Tue, 8 Aug 2006 11:04:38 +0100, Ben Jones <ben.jones@xilinx.com> wrote: >Evan Lavelle <eml@nospam.uk> wrote >> I've never noticed >> *any* similarity between Verilog and C, apart from the most >> superficial. I'd really like to see someone produce a list of these >> similarities. Thanks - I was going to say much the same. Case-sensitivity would be my strongest candidate - and, perhaps, the use of square brackets for array subscripts. Not much else. I guess, though I don't know for sure, that the superficial similarities are because the original authors of Verilog very sensibly saved themselves some work by borrowing lex/yacc parsing technology. [Ben Jones] > In summary: &&, ||, !, &, |, ^, ~, ==, !=. :-) And even that is at the mercy of 4-state logic. (I spy a missed opportunity here. SystemVerilog has not yet assigned a meaning to the :-) operator.) -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 106128
Hi there, I am doing my first FPGA/VHDL design. Previously I did CPLD designs utilizing Altera's AHDL. I coded the VHDL source files and simulated it successfully with Modelsim. Then I made the I/O pin assignments and made the .bit file and loaded it to the FPGA. To my disappointment only some of the signals are correct; the functionality of the system does not work. I am using ispLEVER and a Lattice LFEC33 FPGA. There is a "Post Place and Route Simulation" action available within ispLEVER (actually it starts Modelsim), but this does not work. Modelsim always complains "Error loading design". What possibilities do I have to debug my design? Thanks a lot, JohannesArticle: 106129
Dear all, I'm new to RocketIO and would appreciate any guidance from a hw design perspective. I am currently doing schematics for an application specific development board and trying to work through the various demands from the datasheets and app notes, for example, the fact that it seems to need three additional LDO power supplies?!? Any hints and tips would be useful. TIA -- PeterArticle: 106130
fpgakid@gmail.com wrote: > I've written a Xilinx JTAG programmer. It runs on Win32 and Linux > > Following cables are supported: > > Parallel III > Digilent USB (on Linux it needs libusb, Win32 needs the original driver > from digilent, utilizes full USB transfer speed!) > > Following chips are implemented: > Spartan-3 Family > XCF Family > Virtex-II Pro family > > If it seems people are interested I'll clean up the code and put it up > on sourceforge.net. > The most interesting part is the Digilent USB driver. It could be used > in other applications too :) I would be interested in this. Would the Digilent driver be open source? Is it freely distributed? I looked for info on this at the Digilent site and I did not find any.Article: 106131
rickman schrieb: > fpgakid@gmail.com wrote: > > I've written a Xilinx JTAG programmer. It runs on Win32 and Linux > > > > Following cables are supported: > > > > Parallel III > > Digilent USB (on Linux it needs libusb, Win32 needs the original driver > > from digilent, utilizes full USB transfer speed!) > > > > Following chips are implemented: > > Spartan-3 Family > > XCF Family > > Virtex-II Pro family > > > > If it seems people are interested I'll clean up the code and put it up > > on sourceforge.net. > > The most interesting part is the Digilent USB driver. It could be used > > in other applications too :) > > I would be interested in this. Would the Digilent driver be open > source? Is it freely distributed? I looked for info on this at the > Digilent site and I did not find any. digilent has adept SDK so you can use their cables using their DLL. you cant however access them direclty. AnttiArticle: 106132
Hi Johannes, did you import the testbench file and associate it to the device in ispLEVER? By doing that you can start functional and timing simulation when marking the device. Besides are you using VHDL packages ? Rgds Andr=E9 > There is a "Post Place and Route Simulation" action available within > ispLEVER (actually it starts Modelsim), but this does not work. > Modelsim always complains "Error loading design". > What possibilities do I have to debug my design? >=20 > Thanks a lot, >=20 > JohannesArticle: 106133
Antti wrote: > as long as the platform usb and s3e starte use the same FX2 firmware > and same CPLD file they should be fairly compatible. I imagine the CPLD is identical as the WebPack software just sees it as a Platform USB cable. > the difference could be in additional control outputs of the CPLD as > the platform cable has tri-state busdrivers not present in the > starterkit. so control outputs for them may have to be tied to some > level in the CPLD. > > well thats a guess I have not checked or tried it yet. OK, I am looking at getting a new JTAG dongle since the one work got for free(!) with Altium seems a bit dodgy. (And it's slow and it's parallel) Thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8CArticle: 106134
bijoy wrote: > Hi, The board details are as follows. PCI-32 bit 33 MHz (so M66 is connected to GND) Master/Target functionality. The device does work along with other PCI devices. ( TV tuner card, PCI NIC card etc) Only memory space enabled. Only 1 BAR enabled. Decode speed : medium Clock : PCI clock going to dedicated GCLK pin. FPGA : XC3S200-144TQFP, with XCF01 (1 M flash) (PROM configuration speed is default (6MHz) ) > > What is this PDE ? Also what do you mean by BIOS speed contrary... ? i belive PCI decode speed is not settable in BIOS. > > The exact symptoms are : Intel motherboards -> works fine (845, 865, 915 etc) VIA motherboard A7VBX-MX (AMD) -> PC does not even give the "all ok" single beep at power on. monitor, keyboard, mouse all appear dead. CPU fan keeps whirring but PC does not boot. > > looks like we will have to open a webcase. > > Thanks -Bijoy I had a strange non-boot problem during development of a PCI card that used a PCI target chip (non-FPGA). When the card was plugged into one PC, that PC didn't boot. However, when the card was plugged into other PCs, they always booted. Because the PCI chip's serial EEPROM's setting were wrong, the PCI chip always asserted INTA#. After correcting the EEPROM settings, INTA# behaved correctly, and the first PC always booted. -Dave PollumArticle: 106135
Thanks for all of the advice above. I've tested the ADC using function generators to drive SCLK and CS and it works just fine. So the problem is definitely with my self-generated signals where I have been running the ADC at half the FPGA board speed (and like homoalteraiensis says) deriving the SCLK from the LSB of a counter in the FPGA. But this isn't working. Ki homoalteraiensis wrote: > I had no problem in driving a typical serial ADC's system clk and > control impulses @60Meg and above, which is already very close to the > ADCs spec! > > A common problem is, to generate an approp riate clock with a valid > duty cycle. Here a PLL can be used to obtain a freq which ist no > directly synthesizeable from the FPGAs system clock (just like 100Megs > from out of 60Meg internal or 20Meg external). > > But typically, you will run a ADC with half of the system freq, in > order to be able to do processing and decisions within one bit clock, > and toggle the required signal outputs for any of the peripheric > devices easily.(e.g. Bit0 of a counter, running at clock speed) > > A special case is running the data aquisition fully pipelined, where > ADC's clock is equal to the fpga clock: With most programmable devices, > you will somehow violate the system clock net in simply passing out the > freq itself! You will have to use dual data rate cells instead (which > also should be placed in the io-blocks for best performance). > > If you are not familiar with this: The ddr-cell is a switch for two > channels controlled by a) the high level and b) as well the low level > of the cells's clock. By feeding the ddr cell with static 1 and 0 at > its inputs, it is somehow "abused" to switch a 1 at clk hi, and a zero > at clk lo. Thus it doubles the frequency to obtain the virtual factor 2 > mentioned above (toggeling). > > With a (pll based) well clk inside the FPGA, you will have a nice and > perfectly driven system clk outside too, with a dc of 50:50 (nearly). > > The next issue is aquiring the ADCs output correctly according to the > given delay at the board: Some ADCs pass out their data at the falling > edge, and with a tycical delay of 10ns, so you will find the data valid > in beneath of the next rising edge of the receiving flip flops. To > avoid this, simply generate a doubled system clk and generate a delayed > clock for the ddr-cells' clock to delay the ADCs clock. You may also > invert 0/1 to push the phase in a way, that the incoming data perfectly > meets to aquiring clock.Article: 106136
ZHI wrote: > The Matlab > always > show busy but not continue to next trial. I have to close Matlab and > try again. The phenomenon happens every time. Is this the problem of my > vhdl codes？ Sounds like a Matlab bug. Open a case with them. > But how can it successuflly work for some trials (even > reached 9883 trial)? Memory leaks are like that. > How to fix it? Upgrade Matlab. Maybe try a different computer. -- Mike TreselerArticle: 106137
Ben Jones wrote:
>> I'd really like to see someone produce a list of these
>> similarities.
>
> In summary: &&, ||, !, &, |, ^, ~, ==, !=. :-)
>
> -Ben-
How about:
1. if/else are the same.
2. Verilog "begin" and "end" maps to C's "{" and "}"
3. Verilog's case statement is similar to C's switch statement.
4. Comment characters are the same.
5. Verilog and C statements are both terminated with semicolon.
6. And last but not least, both Verilog and C have "integer" types. ;-)
Article: 106138Has anyone been able to dynamically switch speeds on the V4FX RocketIO?. I've been trying to switch between 2.5GHz and 5GHz using the reconfiguration ports. It works in simulation but not in real hardware. Has anyone else tried to do this?Article: 106139
Hello all, I am working with the Xilinx ML403 board and I am trying to find some documentation about the UDP Multicast performance for the board. Does anyone have any pointers? ThanksArticle: 106140
Johannes Hausensteiner wrote:
> I am doing my first FPGA/VHDL design.
> I coded the VHDL source files and simulated it successfully with
> Modelsim. Then I made the I/O pin assignments and made the .bit
> file and loaded it to the FPGA. To my disappointment only some of
> the signals are correct; the functionality of the system does not
> work.
> I am using ispLEVER and a Lattice LFEC33 FPGA.
> There is a "Post Place and Route Simulation" action available within
> ispLEVER (actually it starts Modelsim), but this does not work.
> Modelsim always complains "Error loading design".
Use modelsim directly from the command line or GUI.
> What possibilities do I have to debug my design?
Common first-time synthesis problems include:
Use of wait statements.
No clock.
No reset.
Inputs not synchronized.
Clock or reset on non-global pin.
Not using standard clocked process template.
If all else fails,
post your code to comp.lang.vhdl
Good luck.
-- Mike Treseler
Article: 106141
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:gcsgd254tgh90tmsdq5pkg2fgl3vmj3bu8@4ax.com...
> On Tue, 8 Aug 2006 11:04:38 +0100, Ben Jones
> <ben.jones@xilinx.com> wrote:
> > In summary: &&, ||, !, &, |, ^, ~, ==, !=. :-)
> And even that is at the mercy of 4-state logic.
Still, I'd rather type '&' than 'and' anyday. :)
> (I spy a missed opportunity here. SystemVerilog has not yet
> assigned a meaning to the :-) operator.)
I believe that happy smilies cannot exist within a standard C-syntax
expression. The lexer requires them to be sad, viz:
r = a?b :-( d+e);
Ah, wait. Unless, of course, they have a big nose:
r = (a?b :0) ;
...or they are very very happy:
r = a?b :-D ;
There must be a standard reference somewhere for this stuff...
-Ben-
Article: 106142
"Ron" <News5@spamex.com> wrote in message news:VQ0Cg.17$Bx.15@fe02.lga...
> >> I'd really like to see someone produce a list of these
> >> similarities.
> > In summary: &&, ||, !, &, |, ^, ~, ==, !=. :-)
> How about:
> 1. if/else are the same.
True, I guess the conditional statements have the same format. There aren't
many different formats to choose from though. :)
> 2. Verilog "begin" and "end" maps to C's "{" and "}"
So that's not very alike at all then...!
> 3. Verilog's case statement is similar to C's switch statement.
Nah, it's nothing like it! There's no equivalent of C's requirement for a
'break' statement at the end of each branch for a start.
> 4. Comment characters are the same.
True, good point.
> 5. Verilog and C statements are both terminated with semicolon.
But there the similarity ends; for example:
module foo;
...
endmodule
WTF?!? Who thought *that* made sense?
> 6. And last but not least, both Verilog and C have "integer" types. ;-)
ROFL! :-)
-Ben-
Article: 106143
On Tue, 08 Aug 2006 07:04:10 -0700,
Ron <News5@spamex.com> wrote:
>How about:
urrm, does the smiley apply to the whole post ?
>1. if/else are the same.
C has a hard time with "if (1'bx)".
>2. Verilog "begin" and "end" maps to C's "{" and "}"
I'll grant you that one.
>3. Verilog's case statement is similar to C's switch statement.
Apart from the facts that:
* each branch is a single statement in Verilog,
whereas C switch is in fact a computed branch and
execution continues through the switch block;
* choices must be prefixed with the keyword "case" in C;
* the syntax for mapping more than one choice
to the same action is different;
* Verilog has two wildcard-matching variants of "case";
* case labels (choices) in Verilog don't need to be constants.
In other respects, yes, they're similar....
>4. Comment characters are the same.
>5. Verilog and C statements are both terminated with semicolon.
OK, I concede.
>6. And last but not least, both Verilog and C have "integer" types. ;-)
with different names and different semantics :-)
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 106144Ben Jones wrote: > "Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message > Still, I'd rather type '&' than 'and' anyday. :) Personally, I'd rather read 'and' than '&'. The old Ada argument is that code is read far more often than it is written. I guess that's why Ada-inspired VHDL ended up as it did. IMHO the world needs both, Verilog for hacking together things at low-level very quickly and easily, VHDL for larger projects, particularly those being written by a large team. There's also plenty of room for personal preference of course... -- PeterArticle: 106145
Evan Lavelle wrote: > Personally, I really hate this sort of code. It was synthesising to > about 75 logic levels between clocks before I started hacking it. I will agree that bad synthesis prevent abstract use, and that given enough time a human can normally find a better solution. On the otherhand, large designs, and fixed market windows, force tradeoffs. And as the complexity of designs grow to take advantage of FPGAs which grow in size with Moore's Law, we probably are not going to see either the number of skilled FPGA hackers (err hardware designers) salary shrink to maintain the same costs or see market windows increasing in length with Moore's Law. So that says, the tools must improve, as must the coding efficiency of hardware hackers. > >I'm actually looking foward to a SystemC tool based > >on C++ sematics that has really good synthesis ... maybe a few years > >from now? > > It'll never happen; already been tried, failed. Hacking low-level > hardware semantics into existing C++ semantics just gives you a > verbose and complex mess, which is nowhere near as concise and clear > as a VHDL or Verilog description. Great for modelling, non-starter for > real-world synthesis. I love people quoting other failures as proof of impossibiity. I'm sure the experience set in this forum is rife with examples of designs that "would never happen", because a few teams failed, and over time other people learn new skills, tricks, tools and find the solutions to previously difficult problems. It wasn't that long ago that the DEC systems engineers defended writing in assembly long after the industry moved past that poor practice. Of course, the industry moved past DEC too. And a couple of my "favorite" hardware companies that swore large TTL design where cheaper, that have long since bit the dust too. > BTW, I google'd FpgaC and spent 10 minutes looking at the SourceForge > site, before giving up. There's no obvious overview, FAQ, or > documentation; you'll need to fix this if you want to get anyone > interested. it's not prime time yet, still has about two more major changes to be release as Beta's this year. There hasn't been a need yet for an FAQ, but everything else in your list is in the Source Forge archive in all the expected spots. http://sourceforge.net/docman/display_doc.php?docid=30867&group_id=152034 http://fpgac.sourceforge.net/ and the current development snapshot gets checked into the publicly accessable svn archive as changes are integrated into the main development tree, including doc updates. I have my own development tree of major hacks and work in progress ideas, that get pushed up to the svn archive as they are nearing a point in development that they ready for others to play with. As a work in progress, it's certainly far from complete today, and probaby would have been a lot farther complete, except for the drowning death of my 11 year old daughter at a friends house in May. As close as I can tell, there are a good few using it, from the periodic emails. Mostly students that are comfortable with the work in progress state of the project, and are willing to spend a small amount of time to hack the tools into a working state for their development environment. Clean, plug and play release which are married well to Altera and Xilinx tools, will probably not happen till Beta-4 around Christmas. At which point FpgaC will go pretty close to production, with some maturity and ease of use work.Article: 106146
On Tue, 08 Aug 2006 12:26:05 +0100, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: >> In summary: &&, ||, !, &, |, ^, ~, ==, !=. :-) > >And even that is at the mercy of 4-state logic. Even for these operators, the usage semantics (as you know) are very different from C's. Sections 4.4/4.5 of the LRM are fantastically complicated (to me, anyway). To quote Steven Sharp from an old c.l.v post on the subject: "I agree that this is not intuitive to someone used to most other programming languages". Too right. >(I spy a missed opportunity here. SystemVerilog has not yet >assigned a meaning to the :-) operator.) Damn... I was going to say that :-)Article: 106147
On Tue, 8 Aug 2006 15:26:05 +0100, "Ben Jones" <ben.jones@xilinx.com> wrote: > >"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message >news:gcsgd254tgh90tmsdq5pkg2fgl3vmj3bu8@4ax.com... >> On Tue, 8 Aug 2006 11:04:38 +0100, Ben Jones >> <ben.jones@xilinx.com> wrote: > >> > In summary: &&, ||, !, &, |, ^, ~, ==, !=. :-) >> And even that is at the mercy of 4-state logic. > >Still, I'd rather type '&' than 'and' anyday. :) That reminds me. C++ has 'and', 'or', 'xor', and 'not' operators. Now, this could just be a bizarre coincidence, but I think not. A more reasonable explanation, I contend, is that Mr. Stroustrup actually based C++ on VHDL. EvanArticle: 106148
Jonathan Bromley wrote: > urrm, does the smiley apply to the whole post ? Certainly not ... as one expression per post can be horribly boring :( > C has a hard time with "if (1'bx)". Ummm ... Why is that construct difficult for C? > Apart from the facts that: > * each branch is a single statement in Verilog, > whereas C switch is in fact a computed branch and > execution continues through the switch block; Something that makes switch statements "interesting" for FpgaC at the moment because of the current "one-hot" notion about flow control. That abstraction however, isn't pure, and will certainly get less pure soon, when switch/case/break/continue are implemented using a mapped set of enables (rather than a pure mux tree). > In other respects, yes, they're similar.... Historically, in the evolution of languages, C defined a number of departures in syntax that have been adopted in new languages rather than the more verbose 1970's styles found in Pascal, ADA, PL/1 predicessors.Article: 106149
Evan Lavelle wrote: > A more > reasonable explanation, I contend, is that Mr. Stroustrup actually > based C++ on VHDL. Hmm ... C++ was presented initially released as part of the programmers workbench sometime in the spring of 1975 if I remember right. Verilog was a decade later in 1985. When was VHDL?
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