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
> I'm interested. Placement will have a huge effect. I look at routed > results for my implementation and I saw one route of 4.5 ns. Looks like > they shoved the input FFs into the IOBs, so the design can't all be > close together as the IO is scattered around the chip perimeter. I'd > need to kill that or add another layer of FFs so the routes of interest > are all internal FFs which could be co-located. Still doesn't say they > *will* be close together. I find tools to be hard to manage in that > regard unless you do floor-planning. I much prefer a slow clock... lol Today I've tried the new method in the real design and it tuned out that it works quite well. Biggest negative timing slack was about -0.047 or so. If I can take an advantage of single cycle operation, I'll try to implement it there. Total delay of critical path there is about 4 ns and it's bigger then in my simple test mostly because of worse routing to LUTs at the beginning and at the end of a dedicated CARRY network.Article: 158551
On 12/21/2015 2:33 PM, Ilya Kalistru wrote: > >> I'm interested. Placement will have a huge effect. I look at routed >> results for my implementation and I saw one route of 4.5 ns. Looks like >> they shoved the input FFs into the IOBs, so the design can't all be >> close together as the IO is scattered around the chip perimeter. I'd >> need to kill that or add another layer of FFs so the routes of interest >> are all internal FFs which could be co-located. Still doesn't say they >> *will* be close together. I find tools to be hard to manage in that >> regard unless you do floor-planning. I much prefer a slow clock... lol > > Today I've tried the new method in the real design and it tuned out that it works quite well. Biggest negative timing slack was about -0.047 or so. If I can take an advantage of single cycle operation, I'll try to implement it there. > Total delay of critical path there is about 4 ns and it's bigger then in my simple test mostly because of worse routing to LUTs at the beginning and at the end of a dedicated CARRY network. Lots of times routing is half the total delay in a design. In this case it may be less because of there just being two routes and the carry chain. But the point is a bad routing delay in just one place can dominate. -- RickArticle: 158552
On 12/21/15 1:57 PM, rickman wrote: > On 12/21/2015 11:26 AM, Gabor Szakacs wrote: >> I have always heard this method referred to as "end around carry," >> however if you are using this as an accumulator, i.e. A is the next >> data input and B is the result of the previous sum, then it is in >> effect the same as taking the sum of inputs modulo 2**32 - 1, with >> the only difference being that the final result can be equal to >> 2**32 - 1 where it would normally be zero. Intermediate results >> equal to 2**32-1 do not change the final outcome vs. doing a true >> modulo operator. > > I guess I see what you are saying, even if this only applies to an > accumulator rather than taking a sum of two arbitrary numbers. When a > sum is equal to 2**N-1 the carry is essentially delayed until the next > cycle. But... if the next value to be added is 2**n-1 (don't know if > this is possible) a carry will happen, but there should be a second > carry which will be missed. So as long as the input domain is > restricted to number from 0 to 2**N-2 this will work if the final result > is adjusted to zero when equal to 2**N-1. > All ones (the alternate to 0 = 2^32-1) plus All ones will give us the result of All ones due to the end around carry (in effect the second carry was remembered by leaving the result as all ones).Article: 158553
I know this subject is very repetitive, but It's very confusing to me. I'm familiar to verilog coding and digital circuit designing but I haven't work with FPGAs. I want to learn it. could you please help me? Thanks.Article: 158554
On December 23rd, 2015, Hamid Kavianathar posted: |--------------------------------------------------------------------| |"I know this subject is very repetitive, but It's very confusing to | |me. I'm familiar to verilog coding and digital circuit designing but| |I haven't work with FPGAs. I want to learn it. could you please help| |me? Thanks." | |--------------------------------------------------------------------| Dear Hamid Kavianathar: This is repetitive and well worth repeating - use VHDL. A good author is Dr. Peter Ashenden. He is the author of "The Student's Guide to VHDL" - WWW.Ashenden.com.Au Regards, Nicholas Collin Paul de GloucesterArticle: 158555
On Wednesday, December 23, 2015 at 7:04:50 AM UTC-8, Nicholas Collin Paul de Gloucester wrote: > On December 23rd, 2015, Hamid Kavianathar posted: > |--------------------------------------------------------------------| > |"I know this subject is very repetitive, but It's very confusing to | > |me. I'm familiar to verilog coding and digital circuit designing but| > |I haven't work with FPGAs. I want to learn it. could you please help| > |me? Thanks." | > |--------------------------------------------------------------------| > > > Dear Hamid Kavianathar: > > This is repetitive and well worth repeating - use VHDL. A good author > is Dr. Peter Ashenden. He is the author of "The Student's Guide to > VHDL" - > WWW.Ashenden.com.Au > > Regards, > Nicholas Collin Paul de Gloucester thanks for your attention. Excuse me, I've studied VHDL. I want to learn how to use ISE, ... .Article: 158556
Hamid Kavianathar wrote: > > thanks for your attention. Excuse me, I've studied VHDL. I want to learn > how to use ISE, ... . Sure. Download Ise and get the webpack license - free, but you have to register and go through some hassle filling out a few forms. I do all my work on smaller FPGAs and CPLDs, so the webpack license supports all the devices I need. Really, there are only a few major parts of Ise you need to be concerned with. First, of course, is the HDL language of your choice. I also prefer VHDL, it may be a hair more verbose and requires you to specify many type conversions, but I think that latter bit is a plus! Second, you need to learn how to run the simulator, and how to build test benches of stimuli for the VHDL logic to respond to. Not real hard, but REALLY gets verbose to flip bits on and off, delay a while, flip some more bits, etc. The last parts are the constraints file and Impact to download the config to real hardware. Xilinx' docs are not bad. If you can't find it there, they have forums that can give a lot of help. JonArticle: 158557
On Wednesday, December 23, 2015 at 10:53:13 AM UTC-8, Jon Elson wrote: > Hamid Kavianathar wrote: > > > > > > thanks for your attention. Excuse me, I've studied VHDL. I want to learn > > how to use ISE, ... . > Sure. Download Ise and get the webpack license - free, but you have to > register and go through some hassle filling out a few forms. > > I do all my work on smaller FPGAs and CPLDs, so the webpack license supports > all the devices I need. > > Really, there are only a few major parts of Ise you need to be concerned > with. First, of course, is the HDL language of your choice. I also prefer > VHDL, it may be a hair more verbose and requires you to specify many type > conversions, but I think that latter bit is a plus! > > Second, you need to learn how to run the simulator, and how to build test > benches of stimuli for the VHDL logic to respond to. Not real hard, but > REALLY gets verbose to flip bits on and off, delay a while, flip some more > bits, etc. > > The last parts are the constraints file and Impact to download the config to > real hardware. > > Xilinx' docs are not bad. If you can't find it there, they have forums that > can give a lot of help. > > Jon thanks Jon. You helped me a lot.Article: 158558
On Wed, 23 Dec 2015 12:53:07 -0600, Jon Elson wrote: > Hamid Kavianathar wrote: > Jon's post is pretty much spot on, I'd only add a slighly different perspective... > I also > prefer VHDL, it may be a hair more verbose and requires you to specify > many type conversions, but I think that latter bit is a plus! I see it differently : if you find yourself writing many type conversions, it usually shows a problem with the design. Something has been declared with the wrong type : step back, look at the design again. When you see it, use the right type in the first place. Most of the conversions will disappear, leaving a cleaner, simpler design. One of VHDL's strengths is the way the type system can help you, if you let it instead of fighting it. > Second, you need to learn how to run the simulator, and how to build > test benches of stimuli for the VHDL logic to respond to. Not real > hard, but REALLY gets verbose to flip bits on and off, delay a while, > flip some more bits, etc. But if you write the same flipping code more than twice, it's time to move it into a procedure. Using VHDL at a higher level, it can become less verbose, more reusable, and certainly easier to understand. Once you have grasped the basics, and move on to more complex projects, you'll want to look at advanced verification tools, such as OSVVM, and the VUnit testing framework. Another strength of VHDL is that these tools are pure VHDL, free, and open-source, where alternatives might require you to move from Verilog to System Verilog and expensive closed source tools. OSVVM: www.osvvm.org VUnit https://github.com/LarsAsplund/vunit https://www.linkedin.com/pulse/free-open-source-verification-vunit-ghdl- lars-asplund?trk=prof-post -- BrianArticle: 158559
On Thursday, December 24, 2015 at 6:54:50 AM UTC-8, Brian Drummond wrote: > On Wed, 23 Dec 2015 12:53:07 -0600, Jon Elson wrote: > > > Hamid Kavianathar wrote: > > > > Jon's post is pretty much spot on, I'd only add a slighly different > perspective... > > > I also > > prefer VHDL, it may be a hair more verbose and requires you to specify > > many type conversions, but I think that latter bit is a plus! > > I see it differently : if you find yourself writing many type > conversions, it usually shows a problem with the design. Something has > been declared with the wrong type : step back, look at the design again. > > When you see it, use the right type in the first place. Most of the > conversions will disappear, leaving a cleaner, simpler design. > > One of VHDL's strengths is the way the type system can help you, if you > let it instead of fighting it. > > > Second, you need to learn how to run the simulator, and how to build > > test benches of stimuli for the VHDL logic to respond to. Not real > > hard, but REALLY gets verbose to flip bits on and off, delay a while, > > flip some more bits, etc. > > But if you write the same flipping code more than twice, it's time to > move it into a procedure. > > Using VHDL at a higher level, it can become less verbose, more reusable, > and certainly easier to understand. > > Once you have grasped the basics, and move on to more complex projects, > you'll want to look at advanced verification tools, such as OSVVM, and > the VUnit testing framework. > > Another strength of VHDL is that these tools are pure VHDL, free, and > open-source, where alternatives might require you to move from Verilog to > System Verilog and expensive closed source tools. > > OSVVM: > www.osvvm.org > > VUnit > https://github.com/LarsAsplund/vunit > https://www.linkedin.com/pulse/free-open-source-verification-vunit-ghdl- > lars-asplund?trk=prof-post > > -- Brian Thanks Brian, your comment is very helpful. after choosing the language, I should learn how to use FPGAs. could you please help me? I need your experience.Article: 158560
This has all been pretty interesting to me because I may need to do this ex=
act thing. I had been planning to do the "end around carry", as you call i=
t, but if that is too slow, I can use Ilya's Shannon Expansion. Ilya's met=
hod (i.e., calculating both A+B and A+B+1 and choosing one based on the car=
ry out) would be much faster at the expense of extra logic. It's just stan=
dard Shannon Expansion but I hadn't thought of it.
I might need to do this for Galois field arithmetic (which is probably the =
case for Ilya as well). One way to multiply GF numbers is to take the logs=
, add them together mod 2^m-1, and then take the inverse log, where 2^m is =
the size of the Galois field. In my case, m is only 10 or 11, so I can use=
lookup tables for the logs and antilogs.
f*g =3D alog (mod ( log(f)+log(g), 2^m-1)) =20
=20
where f,g are elements of GF(2^m)
It's the same process as a slide rule. It doesn't matter if the result of =
the mod ends up being 2^m-1 instead of 0, because the alog() function is a =
lookup table and will still map alog(2^m-1) =3D alog(0) =3D 1.
This method would be especially helpful if you are finding the product of s=
everal GF numbers. So far I've just been using actual GF multipliers. Som=
etimes they are big, but you can get the product in a single cycle, and the=
lookup tables entail latency. Also, if you have to add in a number before=
the next multiplication, you have to go back into the alog domain.
Article: 158561On 12/25/2015 9:04 PM, Kevin Neilson wrote: > This has all been pretty interesting to me because I may need to do > this exact thing. I had been planning to do the "end around carry", > as you call it, but if that is too slow, I can use Ilya's Shannon > Expansion. Ilya's method (i.e., calculating both A+B and A+B+1 and > choosing one based on the carry out) would be much faster at the > expense of extra logic. It's just standard Shannon Expansion but I > hadn't thought of it. Uh, if you read Ilya's posts the 64 bit carry chain was faster than the muxed selection. Or did I misunderstand this? > I might need to do this for Galois field arithmetic (which is > probably the case for Ilya as well). One way to multiply GF numbers > is to take the logs, add them together mod 2^m-1, and then take the > inverse log, where 2^m is the size of the Galois field. In my case, > m is only 10 or 11, so I can use lookup tables for the logs and > antilogs. > > f*g = alog (mod ( log(f)+log(g), 2^m-1)) > > where f,g are elements of GF(2^m) > > It's the same process as a slide rule. It doesn't matter if the > result of the mod ends up being 2^m-1 instead of 0, because the > alog() function is a lookup table and will still map alog(2^m-1) = > alog(0) = 1. > > This method would be especially helpful if you are finding the > product of several GF numbers. So far I've just been using actual GF > multipliers. Sometimes they are big, but you can get the product in > a single cycle, and the lookup tables entail latency. Also, if you > have to add in a number before the next multiplication, you have to > go back into the alog domain. > -- RickArticle: 158562
> Uh, if you read Ilya's posts the 64 bit carry chain was faster than the > muxed selection. Or did I misunderstand this? I hadn't seen the part about the 64-bit add. That's a nice idea, too. I wouldn't have expected it to be faster than the basic Shannon Expander, but with the quirks of getting data on and off the carry chain, it doesn't surprise me that it is. This is somewhat unrelated, but I just remembered that recently I had to make a circuit to find modulo-24. I tried several things, but what ended up being fastest and smallest, by far, was mathematically rephrasing the expression, something like this: reg [11:0] x; reg [4:0] x_mod_24; ... x_mod_24 = ((x>>3)%3)<<3 & x[2:0];Article: 158563
On 12/26/2015 9:01 PM, Kevin Neilson wrote: >> Uh, if you read Ilya's posts the 64 bit carry chain was faster than the >> muxed selection. Or did I misunderstand this? > > I hadn't seen the part about the 64-bit add. That's a nice idea, too. I wouldn't have expected it to be faster than the basic Shannon Expander, but with the quirks of getting data on and off the carry chain, it doesn't surprise me that it is. I don't think it has anything to do with getting "data on and off the carry chain". The slow part of FPGAs is often just routing. The 64 bit add eliminates a lot of routing that is needed to implement the mux as well as eliminating the mux itself. > This is somewhat unrelated, but I just remembered that recently I had to make a circuit to find modulo-24. I tried several things, but what ended up being fastest and smallest, by far, was mathematically rephrasing the expression, something like this: > > reg [11:0] x; > reg [4:0] x_mod_24; > ... > x_mod_24 = ((x>>3)%3)<<3 & x[2:0]; Interesting. I guess a divide by 24 is a lot more complex than a divide by 3 even though it doesn't have to be. -- RickArticle: 158564
On 12/25/2015 5:34 AM, Hamid Kavianathar wrote: > > Thanks Brian, your comment is very helpful. after choosing the language, I should learn how to use FPGAs. could you please help me? I need your experience. The tools have their own peculiarities. I am no longer familiar with the Xilinx tools. The parts all the tools have in common is that you have to specify your pin out with attention to the location of special purpose signals like clocks or differential I/Os. You will also need to set up timing constraints to help placement and routing to meet your needs for speed. If you have a design that will be hard to meet timing, you may need to specify placement of critical components. That is very unique to each brand of tool. -- RickArticle: 158565
On Wednesday, November 25, 2015 at 2:29:15 AM UTC+6, Mike Field wrote: > I had a look at the datasheet at http://web.mit.edu/6.111/www/f2009/handouts/labs/ADV7125.pdf > > Maybe you also need to drive the "blank" pin, or the "psave".... > > It would pay to check the schematic... Hello , thank you for your answer. I generate psave,nsync,nblank and 5 common signals and it starts to work normal, thank you everyone !!!Article: 158566
I started learning on my own after I bought an Altera dev board. They have great documentation and video tutorials and their software is fairly intuitive. After you create an account go to their documentation section and take a look. Would recommend this board for the price and available resources (it's 30$ on Arrow). It has some tutorials to get you started: http://www.alterawiki.com/wiki/BeMicro_Max_10 http://www.alterawiki.com/uploads/5/52/BeMicroM10_Simple_PWM_Lab.pdf The single best moment while learning was when I managed to get VGA output to my monitor. It required some soldering though - there are more expensive boards that have the plug already connected: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=921 http://www.fpga4fun.com/PongGame.html On Sunday, December 27, 2015 at 2:15:03 AM UTC-3, rickman wrote: > On 12/25/2015 5:34 AM, Hamid Kavianathar wrote: > > > > Thanks Brian, your comment is very helpful. after choosing the language, I should learn how to use FPGAs. could you please help me? I need your experience. > > The tools have their own peculiarities. I am no longer familiar with > the Xilinx tools. The parts all the tools have in common is that you > have to specify your pin out with attention to the location of special > purpose signals like clocks or differential I/Os. You will also need to > set up timing constraints to help placement and routing to meet your > needs for speed. > > If you have a design that will be hard to meet timing, you may need to > specify placement of critical components. That is very unique to each > brand of tool. > > -- > > RickArticle: 158567
On 12/27/2015 12:18 PM, Emilian Miron wrote: > I started learning on my own after I bought an Altera dev board. They have great documentation and video tutorials and their software is fairly intuitive. After you create an account go to their documentation section and take a look. > > Would recommend this board for the price and available resources (it's 30$ on Arrow). It has some tutorials to get you started: > http://www.alterawiki.com/wiki/BeMicro_Max_10 > http://www.alterawiki.com/uploads/5/52/BeMicroM10_Simple_PWM_Lab.pdf > > The single best moment while learning was when I managed to get VGA output to my monitor. It required some soldering though - there are more expensive boards that have the plug already connected: > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=921 > > http://www.fpga4fun.com/PongGame.html Yeah, not bad. I recently got one of these... http://www.em.avnet.com/en-us/design/drc/Pages/Microsemi-SmartFusion2-KickStart-Development-Kit.aspx http://www.microsemi.com/products/fpga-soc/design-resources/dev-kits/smartfusion2/kickstart-kit Haven't done much with it yet, still learning the tools. They have an Android app to test the Bluetooth but I don't have anything Android. Durn. -- RickArticle: 158568
'Making a simple, structured and efficient VHDL testbench - Step-by-step' is a powerpoint presentation and free webinar that shows novices how to get started making good testbenches, *and* experienced designers how to properly structure your testbenches. The example DUT is a very simple interrupt controller, and the testbench itself uses the free and open source Bitvis Utility Library (compatible with VHDL 93, 2002 and 2008). http://bitvis.no/resources/bitvis-utility-library-download This library has a very low user threshold, so you're up and running directly after watching the presentation. For simplicity reasons Bitvis Utility Library hides the more advanced options for novices, making it easy to get started, and at the same time allowing more advanced use when needed. Bitvis Utility Library is being replaced by UVVM Utility Library (also free and open source) to allow even more advanced options. UVVM Utility Library requires VHDL 2008. http://bitvis.no/resources/uvvm-utility-library-download/Article: 158569
> > This is somewhat unrelated, but I just remembered that recently I had t= o make a circuit to find modulo-24. I tried several things, but what ended= up being fastest and smallest, by far, was mathematically rephrasing the e= xpression, something like this: > > > > reg [11:0] x; > > reg [4:0] x_mod_24; > > ... > > x_mod_24 =3D ((x>>3)%3)<<3 & x[2:0]; >=20 > Interesting. I guess a divide by 24 is a lot more complex than a divide= =20 > by 3 even though it doesn't have to be. Doing a division is one way to do it, but if you look at what the synthesiz= er does to do mod-24, it's something like this: x_mod_24_stage1 =3D x[11]*( (1<<11)%24) + x[10]*( (1<<10)%24) ... + x[3:0]; adding up the mod-24 values due to each bit (and then adding the last 3 bit= s, which are already mod-24). These are all 5-bit values. After you add t= hese, the result may be bigger than 24 and there's a second and third stage= of this process. When you do it the "rephrased" way, the mod-3 logic is a= lot smaller (the sums are all 2 bits) and has fewer stages.Article: 158570
On 12/29/2015 12:17 PM, Kevin Neilson wrote: >>> This is somewhat unrelated, but I just remembered that recently I had to make a circuit to find modulo-24. I tried several things, but what ended up being fastest and smallest, by far, was mathematically rephrasing the expression, something like this: >>> >>> reg [11:0] x; >>> reg [4:0] x_mod_24; >>> ... >>> x_mod_24 = ((x>>3)%3)<<3 & x[2:0]; >> >> Interesting. I guess a divide by 24 is a lot more complex than a divide >> by 3 even though it doesn't have to be. > > Doing a division is one way to do it, but if you look at what the synthesizer does to do mod-24, it's something like this: > > x_mod_24_stage1 = x[11]*( (1<<11)%24) + x[10]*( (1<<10)%24) ... + x[3:0]; > > adding up the mod-24 values due to each bit (and then adding the last 3 bits, which are already mod-24). These are all 5-bit values. After you add these, the result may be bigger than 24 and there's a second and third stage of this process. When you do it the "rephrased" way, the mod-3 logic is a lot smaller (the sums are all 2 bits) and has fewer stages. But clearly there is no need for it to be more complex. What you describe above is essentially a product. I think there last term should be x[2:0] which is the three lsbs. These bits on the output are only affected by the three lsbs of the input. The upper bits of the input can only affect the upper bits of the output. So clearly there is no reason for the tool to calculate the entire 5 bits of the output based on the entire N bits of the input. -- RickArticle: 158571
Folks, Sorry if this is off-topic. I have a project that uses the above board, which has an Spartan 3E chip and an EEPROM for holding the config. If I load Impact on its own I can program the prom, press reset and the code runs. If I run the same step from within ISE it fails as I havn't assigned a file to the FPGA chip, and its on the JTAG chain and I haven't assigned a file. If I remove it from the config in the Impact project it fails because Impact does a boundry scan and finds it and complains because no file is assigned. Any idea what I am doing wrong? Dave WadeArticle: 158572
On January 2nd, 2016, David Wade sent: |-----------------------------------| |"Folks, | |Sorry if this is off-topic. [. . .]| |[. . .]" | |-----------------------------------| It is on topic. |-----------------------------------| |"[. . .] | | | |Any idea what I am doing wrong? | | | |Dave Wade" | |-----------------------------------| Blaming thyself instead of Xilinx. Regards, Paul Colin GlosterArticle: 158573
David Wade wrote: > Folks, > Sorry if this is off-topic. I have a project that uses the above board, > which has an Spartan 3E chip and an EEPROM for holding the config. > > If I load Impact on its own I can program the prom, press reset and the > code runs. > > If I run the same step from within ISE it fails as I havn't assigned a > file to the FPGA chip, and its on the JTAG chain and I haven't assigned > a file. > > If I remove it from the config in the Impact project it fails because > Impact does a boundry scan and finds it and complains because no file is > assigned. > > Any idea what I am doing wrong? > > Dave Wade Impact is very poorly integrated into ISE. I have found that the only reliable way to open Impact from an ISE project is to use the process "Manage Configuration Project (iMPACT)" under "Configure Target Device." Out of curiosity, what version of ISE are you running, and what operating system? -- GaborArticle: 158574
On 04/01/2016 21:40, GaborSzakacs wrote: > David Wade wrote: >> Folks, >> Sorry if this is off-topic. I have a project that uses the above >> board, which has an Spartan 3E chip and an EEPROM for holding the config. >> >> If I load Impact on its own I can program the prom, press reset and >> the code runs. >> >> If I run the same step from within ISE it fails as I havn't assigned a >> file to the FPGA chip, and its on the JTAG chain and I haven't >> assigned a file. >> >> If I remove it from the config in the Impact project it fails because >> Impact does a boundry scan and finds it and complains because no file >> is assigned. >> >> Any idea what I am doing wrong? >> >> Dave Wade > > Impact is very poorly integrated into ISE. I have found that the only > reliable way to open Impact from an ISE project is to use the process > "Manage Configuration Project (iMPACT)" under "Configure Target Device." > This is working for me... ... but it feels like my Nexys 2 board which I can program with the Digilent Adept tools is much cleaner to use even though it is less capable.... > Out of curiosity, what version of ISE are you running, and what > operating system? > For this project 14.1 on Windows/10 (there is a minor hack to get it owrking).... Dave G4UGM
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