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
fpga_toys@yahoo.com wrote: > 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? hmm ... so much for memory ... googling seems place it early 1980's too.Article: 106151
On Tue, 08 Aug 2006 16:59:59 +0100, Evan Lavelle <eml@nospam.uk> wrote: >Even for these [bitwise logic] >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. We must be grateful for small mercies. At least it's written down in the LRM now. Until V-2001, the only place to go for real understanding of Verilog's bit width rules was Steven Sharp's consistently informative and precise postings on c.l.v. And don't even ask about short-circuit evaluation of boolean expressions... another non-similarity between C and Verilog. -- 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: 106152
On 8 Aug 2006 09:24:56 -0700, fpga_toys@yahoo.com wrote: >hmm ... so much for memory ... googling seems place it [C++] >early 1980's too. I had understood that Stroustrup was working on "C with Classes" (using a preprocessor to map from CwC to pure C) from around 1978. Methinks Evan was being whimsical about VHDL... -- 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: 106153
On Mon, 07 Aug 2006 17:53:50 +0200, Nicolas Matringe <nicolas.matringe@fre.fre> wrote: >I can't remember who in this newsgroup who knows both and, whichever >he's using at any given moment, always regrets he doesn't use the other >language. I think that's Janick Bergeron's line originally, but it gets my vote! -- 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: 106154
Evan Lavelle wrote:
> 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 have some semi-abstract reference code below that has been
synthesized successfully on everything except DC.
I would appreciate it if you could give it a go on DC
with and without map_to_entity.
Thanks.
-- Mike Treseler
http://home.comcast.net/~mike_treseler/uart.vhd
Article: 106155Is DSP black art? Like a painting where everything is black? I was under the impression that signal integrity was black art/magic. Anyway, I actually mentioned one of those two in my post :) -burns Nial Stewart skrev: > I'm surprised no-one's mentioned Ray Andraka, he who mixes > the black arts (DSP stuff) with FPGAs and seems to know what he's > talking about ;-) > > He and Peter Alfke would be my two nominations. > > > > NialArticle: 106156
Mike Treseler wrote: > I have some semi-abstract reference code below that has been > synthesized successfully on everything except DC. > I would appreciate it if you could give it a go on DC > with and without map_to_entity. > http://home.comcast.net/~mike_treseler/uart.vhd Thanks ... interesting reference point! Any mappings to Virtex-5 fat lut's yet? Best case hand design for comparison?Article: 106157
On 7 Aug 2006 07:37:19 -0700, "rickman" <spamgoeshere4@yahoo.com> wrote: >It seems to be a common practice to disregard the chaining capabilities >of JTAG unless you really have to save the board space. Instead give >each chip a separate connector. During development this will let you >use multiple tools at the same time and if you need boundary scan in >manufacturing they make tools that will drive multiple chains. Thanks Rick. We've actually got 3 chains on this board, covering 17 devices. The company doing the JTAG kit and software seem to be happy with the arrangement, but we'll have to wait and see how it turns out. A single 2.5V JTAG chain for the Spartan only solves half of this problem, though, since there are still 5 pins connected between the spartan and the PROM. It seems to me to make more sense to run Vcco on the PROM at 2.5V (rather than 3.3V, which is the official line from XAPP453), for the simple reason that the XCF04S is much more tolerant to high input voltages than the Spartan. I'll give it a go and see. EvanArticle: 106158
Of course, for legal reasons, I must clearly disclaim this is my own personal opinion and not that of my employer: Philip Freidin is one who has achieved the final goal on this particular path and is a guiding light to the student walking the path. On a material level, he is someone like Michelangelo for an artist. As a user of FPGA technology, he has affected you -- whether he has physically appeared to you or not. Mediating on him guides your logic design.Article: 106159
Hi all, we are trying to implement a 100 MBit communication link witch uses manchester coding. The signal is generated by a CPLD (xc2c64a) and we hope we can receive it with an FPGA (Virtex4 for example). Because the CPLD design will work at 2.5V and should use minimal power (sensor node) my question is if it is possible to use a crystal with a NOT-gate in the CPLD for generating the oszillator frequency instead of an external oszillator. The second question concerns the reception of the datastream within the FPGA. My thought was to use a digital pll as mentioned here http://www.erg.abdn.ac.uk/users/gorry/course/phy-pages/dpll.html to generate a sample clock for the incomming bitstream. With the help of a DCM module I would generate two 300 MHz clocks, one shifted by 180 degree. Then I should be able to sample the incomming stream with 600 MHz and I hope this is enough to stay phase locked with the datastream. But I haven't done such a fast communication before, so I've no idea if this will work. Any comments from you would be nice. Thanks, MichaelArticle: 106160
On Tue, 08 Aug 2006 10:05:10 -0700, Mike Treseler <mike_treseler@comcast.net> wrote: >Evan Lavelle wrote: > >> 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 have some semi-abstract reference code below that has been >synthesized successfully on everything except DC. >I would appreciate it if you could give it a go on DC >with and without map_to_entity. It's a client's software, I'm afraid, so no can do. It's also worth more than I make in a year. 'map_to_entity' is a pragma that you enter in the source code, together with your behavioural function/procedure. All it says is that, during synthesis, the subprogram call should be replaced with an instantiation of the named entity (in other words, it's not something that you can try running with or without; you have to write the code). EvanArticle: 106161
Michael, The use of a CPLD or FPGA inversion is not recommended for a crystal oscillator. The problem is not that it won't work (it often does), it is that it sometimes will not start. The inversion also comes with a delay that is not something that you can easily model and prove that the oscillator will always start up. Once started, it will oscillate, it is the starting that is sometimes difficult, Austin Michael Dreschmann wrote: > Hi all, > > we are trying to implement a 100 MBit communication link witch uses > manchester coding. The signal is generated by a CPLD (xc2c64a) and we > hope we can receive it with an FPGA (Virtex4 for example). > Because the CPLD design will work at 2.5V and should use minimal power > (sensor node) my question is if it is possible to use a crystal with a > NOT-gate in the CPLD for generating the oszillator frequency instead > of an external oszillator. > The second question concerns the reception of the datastream within > the FPGA. My thought was to use a digital pll as mentioned here > http://www.erg.abdn.ac.uk/users/gorry/course/phy-pages/dpll.html > to generate a sample clock for the incomming bitstream. > With the help of a DCM module I would generate two 300 MHz clocks, one > shifted by 180 degree. Then I should be able to sample the incomming > stream with 600 MHz and I hope this is enough to stay phase locked > with the datastream. But I haven't done such a fast communication > before, so I've no idea if this will work. Any comments from you would > be nice. > > Thanks, > MichaelArticle: 106162
Michael, Comments inline. "Michael Dreschmann" <michaeldre@gmx.de> wrote in message news:44d8c7e4.91526812@news.rhein-zeitung.de... > Hi all, > > we are trying to implement a 100 MBit communication link witch uses > manchester coding. The signal is generated by a CPLD (xc2c64a) and we > hope we can receive it with an FPGA (Virtex4 for example). > Because the CPLD design will work at 2.5V and should use minimal power > (sensor node) my question is if it is possible to use a crystal with a > NOT-gate in the CPLD for generating the oszillator frequency instead > of an external oszillator. No, I don't think this will work. You need an unbuffered inverter, don't think the CPLD will have this. > The second question concerns the reception of the datastream within > the FPGA. My thought was to use a digital pll as mentioned here > http://www.erg.abdn.ac.uk/users/gorry/course/phy-pages/dpll.html > to generate a sample clock for the incomming bitstream. > With the help of a DCM module I would generate two 300 MHz clocks, one > shifted by 180 degree. Then I should be able to sample the incomming > stream with 600 MHz and I hope this is enough to stay phase locked > with the datastream. But I haven't done such a fast communication > before, so I've no idea if this will work. Any comments from you would > be nice. > Yep, that works. I've recovered RZ data with a 4 times clock, same thing applies to Manchester coding, so you'd be able to do it with a 200MHz clock on the DDR IOB input registers. Check out XAPP224. HTH, Syms.Article: 106163
Michael Dreschmann schrieb: > Hi all, > > we are trying to implement a 100 MBit communication link witch uses > manchester coding. The signal is generated by a CPLD (xc2c64a) and we > hope we can receive it with an FPGA (Virtex4 for example). > Because the CPLD design will work at 2.5V and should use minimal power > (sensor node) my question is if it is possible to use a crystal with a > NOT-gate in the CPLD for generating the oszillator frequency instead > of an external oszillator. > The second question concerns the reception of the datastream within > the FPGA. My thought was to use a digital pll as mentioned here > http://www.erg.abdn.ac.uk/users/gorry/course/phy-pages/dpll.html > to generate a sample clock for the incomming bitstream. > With the help of a DCM module I would generate two 300 MHz clocks, one > shifted by 180 degree. Then I should be able to sample the incomming > stream with 600 MHz and I hope this is enough to stay phase locked > with the datastream. But I haven't done such a fast communication > before, so I've no idea if this will work. Any comments from you would > be nice. > > Thanks, > Michael you can look at the USB DPLL get the sub phy from opencores as example it uses 4x clock to deliver mid-bit clock enable to latch the data. something similar should work for manchester as well. cpld oscillator shure work, but you still need a resistor across not gate in-out it want oscillate otherwise. I have spent some time trying to get an crystal to swing on FPGA pins without external resistor but have not yet succeeded. AnttiArticle: 106164
"Eric Crabill" <eric.crabill@xilinx.com> wrote in message news:ebai5b$32i1@cliff.xsj.xilinx.com... > Of course, for legal reasons, I must clearly disclaim this is my own > personal opinion and not that of my employer: > > Philip Freidin is one who has achieved the final goal on this particular > path and is a guiding light to the student walking the path. On a material > level, he is someone like Michelangelo for an artist. As a user of FPGA > technology, he has affected you -- whether he has physically appeared to > you > or not. Mediating on him guides your logic design. > > :-)Article: 106165
"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag news:44D8D028.7080802@xilinx.com... > Michael, > > The use of a CPLD or FPGA inversion is not recommended for a crystal > oscillator. > > The problem is not that it won't work (it often does), it is that it > sometimes will not start. The inversion also comes with a delay that is > not something that you can easily model and prove that the oscillator > will always start up. > > Once started, it will oscillate, it is the starting that is sometimes > difficult, > > Austin hm you mean that an CPLD/FPGA NOT gate with 1 (or 2 resistors) and 2 caps and crystal will not oscillate under some conditions? It should be 100% a-stable as it can not stay in non-oscillating state. AnttiArticle: 106166
fpga_toys@yahoo.com wrote:
> Any mappings to Virtex-5 fat lut's yet?
No. Try it and let me know.
I'll add the stats to the table
at the end of the file.
> Best case hand design for comparison?
After looking at the Quartus RTL view
http://home.comcast.net/~mike_treseler/uart.pdf
I don't think I could make much less area.
Anyway, life's too short :)
-- Mike Treseler
Article: 106167bart schrieb: > burn.sir@gmail.com wrote: > > > And the guy at Lattice who wrote Mico8 and released it under GPL. > > > -Bruns > Do you have more input on open source IP's for FPGAs? Gordon Hands from > Lattice is looking for just that type of feedback on his blog. Gordon > was heavily involved in the Open IP cores licensing agreement and is > looking for more feedback... > > Gordon writes: "I would be interested in reading comments from users on > this topic. Does it make sense to have Open Source IPs for FPGAs? > Should Lattice be doing more of this?" > > here's the link to his blog: > http://latticeblogs.typepad.com/frontier/author_gordon_hands/index.html > > Regards, > Bart Borosky, Lattice Hi Bart, should Lattice do more? The answer is YES. ok, kidding its up to you folks to decide what you do of course :) But what I can say is that very often when some FPGA softcore topic pops up then there will someone say, hey look the Mico8 from Lattice its OpenSource! So I would the say the "Lattice Open-Source initiatiave" has got a warm greeting from all around. Another thing is that what could be that "open-source from Lattice?" Hm, I actually I do know. I was actually even thinking about making an public announcment and putting some $$ valuable FPGA boards to the one that makes the dream machine: The goal would be: RISC CPU with SDRAM controller that fits into LFXP3 and is able to run uClinux. If someone takes the challenge please feel to contact me - I do have some FPGA hardware I might be willing to part of. I think the challeange is possible. May require some tricks though and possible custom GCC, etc.. Anyway as XP second generation is coming soon then this may not even be so interesting anymore. Gee, LFXP3 + sdram chip and sd card socket == uClinux machine? That would be still really coool! It only requires 3.3V supply could even be moutned on proto board with some care. Almost as fun as those Z80 based DIY homecomputers some decades ago. But I guess not worth the work, its easier to have S3e-250 to run uClinux - no custom work required. Not as elegant though as it requires multiply power supplies. just thinkig... AnttiArticle: 106168
Evan Lavelle wrote:
> It's a client's software, I'm afraid, so no can do. It's also worth
> more than I make in a year.
It *costs* more that a year's pay,
but its worth is open for discussion.
> 'map_to_entity' is a pragma that you enter in the source code,
> together with your behavioural function/procedure. All it says is
> that, during synthesis, the subprogram call should be replaced with an
> instantiation of the named entity (in other words, it's not something
> that you can try running with or without; you have to write the code).
Hmm. Do-it-yourself synthesis.
There was a Far Side cartoon that depicted one cave dweller holding a
single round stone in his hand with another cave dweller holding a 'tool
box' full of more of the same round stones. The first guy holding the
single stone exclaims: "I asked for a hammer, A HAMMER! This is a
crescent wrench...... Well, maybe it's a hammer. DAMN these stone tools!"
-- Mike Treseler
Article: 106169Well, it might actually work, perhaps even reliably. But I prefer a dedicated oscillator, because it uses less power, and uses an internal chip that is optimized for the purpose, and is manufactured by a company with expertise and a single-minded goal. And it hardly costs extra... Peter Alfke, Xilinx (back from vacation in Provence...:-) Antti Lukats wrote: > "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag > news:44D8D028.7080802@xilinx.com... > > Michael, > > > > The use of a CPLD or FPGA inversion is not recommended for a crystal > > oscillator. > > > > The problem is not that it won't work (it often does), it is that it > > sometimes will not start. The inversion also comes with a delay that is > > not something that you can easily model and prove that the oscillator > > will always start up. > > > > Once started, it will oscillate, it is the starting that is sometimes > > difficult, > > > > Austin > > hm you mean that an CPLD/FPGA NOT gate with 1 (or 2 resistors) and 2 caps > and crystal will not oscillate under some conditions? > > It should be 100% a-stable as it can not stay in non-oscillating state. > > AnttiArticle: 106170
http://www.sump.org/projects/analyzer/ (link info with thanks to Carsten) AnttiArticle: 106171
On 8 Aug 2006 11:30:03 -0700, "Peter Alfke" <peter@xilinx.com> wrote: >But I prefer a dedicated oscillator, because it uses less power, and >uses an internal chip that is optimized for the purpose, and is >manufactured by a company with expertise and a single-minded goal. And >it hardly costs extra... Costs are no problem, it's a university project and not a design for production. I thought a crystal in combination with the cpld would need less power than a dedicated oscillator. Could you give me a hint where to find a 100 MHz low power oscialltor working at 2.5V? An external oscillator of course would be easier. An other question concerning power: If I have a design that fits exactly in a xc2c64a cpld and I use the next bigger one (xc2c128) with the same design how much more would be the power consumption (roughly)? Thanks, MichaelArticle: 106172
Johannes Hausensteiner wrote: > What possibilities do I have to debug my design? Hi Johannes, besides comp.arch.fpga and other usenet groups, you could post your questions on Lattice's support forum: http://www.latticesemi.com/support/forums.cfm hope this helps. regards, bart borosky, latticeArticle: 106173
Antti, That is exactly what I meant (and also echoed by other posters). When is a not gate not a not? When it has too much delay. Austin Antti Lukats wrote: > "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag > news:44D8D028.7080802@xilinx.com... >> Michael, >> >> The use of a CPLD or FPGA inversion is not recommended for a crystal >> oscillator. >> >> The problem is not that it won't work (it often does), it is that it >> sometimes will not start. The inversion also comes with a delay that is >> not something that you can easily model and prove that the oscillator >> will always start up. >> >> Once started, it will oscillate, it is the starting that is sometimes >> difficult, >> >> Austin > > hm you mean that an CPLD/FPGA NOT gate with 1 (or 2 resistors) and 2 caps > and crystal will not oscillate under some conditions? > > It should be 100% a-stable as it can not stay in non-oscillating state. > > Antti > >Article: 106174
On Tue, 8 Aug 2006 10:37:46 -0700, "Eric Crabill" <eric.crabill@xilinx.com> wrote: >Philip Freidin is one who has achieved the final goal on this particular >path and is a guiding light to the student walking the path. On a material >level, he is someone like Michelangelo for an artist. I agree completely. And the ceiling in his office is spectacular. Bob Perlman Cambrian Design Works http://www.cambriandesign.com
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