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 09/10/2013 18:48, Tim Wescott wrote: > On Wed, 09 Oct 2013 10:02:43 -0700, Paulo Ricardo Pabst wrote: > >> Hi, >> >> I'm new on this group. I'm starting my final year's project and I'm >> building a "interpolated multi-axis controller" (aka NC controller). >> >> I will use a FPGA (probably an spartan 3) to build a DDS, a quadrature >> encoder interface and some others digital circuits. >> >> My knowledge about VHDL is not really good, I'd read some tutorials >> about VHDL and I played with VHDL a little. But what I don't know is the >> best way to implement these digital circuits. >> >> So, what I want is some suggestions about what book I need to buy to >> learn how implement configuration registers, QEI, DDS, microcontroller >> interface, etc. I see some books on amazon, but I'm still in doubt about >> them. > > How much do you know about digital design already? A good VHDL book > isn't going to tell you much about digital design -- it's going to tell > you how, after you know what you want, you can translate that desire into > VHDL. So if your first problem is that you have no clue what a DDS, a > quadrature encoder interface, and those other digital circuits should do, > then your primary need is not a VHDL book. > > If that's the case, then you want to look for a book with a title that's > more along the line of "Digital Logic Design (with VHDL)"; i.e., you want > a book about digital logic design that uses VHDL to convey the design > content. This will fill in your most crying need, and hopefully give you > enough VHDL chops to get you by. > > The book on my shelf is the opposite. It's "The Designer's Guide to VHDL" > by Peter Ashenden, and its meant for people who know digital design, but > not VHDL. > > Keep in mind, though, that I'm no VHDL expert, and the book was just the > likeliest-looking one at Powell's when I went shopping. I'd look to it > only if no one else coughs up a title. It proved adequate to what I was > doing, but what I was doing was largely showing that an algorithm was > feasible _at all_; once I had a first cut working the real FPGA designers > on the project took it out of my hands and made it work with fewer gates > and at a higher clock rate and all that good stuff. > > Unless your prof is demanding that you do this with an FPGA, or unless > you want to use an FPGA just because, you may want to consider > implementing those functions on the microcontroller that you're > interfacing with. I'm certainly not saying you definitely _should_ -- > I've just found that it's often cheaper to pull moderate-speed "logic" > functions into the micro, particularly if I'm at liberty to shop for the > microprocessor I need (for instance: many micros these days are made > specifically for motor control, and have quadrature encoder interfaces > built in). > I'm with Tim on this - use a micro if you can. I've found all books on VHDL or Verilog to be deeply disappointing. The best/quickest way to get started in a goodish direction is to go on a course but it's not cheap. I've been using VHDL for years (started with a 1 week course by Esperan who don't exist any more.) The only book I have which I would even slightly recommend is VHDL 2008 Just the New Stuff by Ashenden and Lewis. It's NOT a book to start with. If you have to do it all on your own trawl the web - there is a lot of "very first step" stuff and quite a lot of useful more advanced material but it can be hard sorting the good from the bad. At least it's free. (The last Verilog book I bought was over £100 and its just trash.) BTW if you are at Uni aren't they meant to TEACH you the basic stuff ? Good luck ! Michael KellettArticle: 155876
I have been programming FPGA with VHDL for some years now. I came from high= -speed full-custom and digital standard cell semiconductor design with cade= nce and that was 100% schematic capture. I have two books: FPGA prototyping by VHDL examples, by Pong P. Chu Circuit Design with VHDL, by Volnei A. Pedroni. Both books gave me a good introduction to the procedure of mapping somethin= g structural (schematic, block diagram) into something behavioural (RTL, FS= M), and at the same time cover something I knew, real hardware. Chu is using Xilinx and Pedroni seems agnostic. Chu has a short tutorial on a Xilinx project to get started with the toolch= ain, and Pedroni has tutorials for Xilinx and Altera. I didn't follow any o= f these tutorials as I pretty much understood the FPGA tools by previous to= ol experience. You can have a peek into both books at google books. Pedroni has a lot of examples on how to use types, both working examples an= d examples which will not work. That's the section I use most nowadays. Other than that, Xilinx has some documents on coding style, both for esthet= ics and for speed. Google for "xilinx coding guidelines" as they are hidden= in obscure places. The switch from schematic structural thinking to VHDL behavioural thinking = sometimes lead to horrible code. The above books helped me through that per= iod, specially regarding use of clock enable instead of gated clocks and av= oid inferring unwanted latches. Just remember to replace the clk'event and = clk=3D'1' with the modern rising_edge(clk) in the textbook examples. The biggest hurdle was to accept that the synthesizer could do a better job= than me and stop being too clever during design. --=20 SvennArticle: 155877
On 10/10/2013 09:46, MK wrote: .. > > I've been using VHDL for years (started with a 1 week course by Esperan > who don't exist any more.) they are still alive and kicking... Hans www.ht-lab.comArticle: 155878
On 10/10/2013 10:38, HT-Lab wrote: > On 10/10/2013 09:46, MK wrote: > > .. >> >> I've been using VHDL for years (started with a 1 week course by Esperan >> who don't exist any more.) > > they are still alive and kicking... > > Hans > www.ht-lab.com > > > Well so they are - I was sure they'd gone. Perhaps I'll ask them about their Verilog for VHDL users course. Michael KellettArticle: 155879
Em quinta-feira, 10 de outubro de 2013 08h07min48s UTC-7, MK escreveu: > On 10/10/2013 10:38, HT-Lab wrote: > > > On 10/10/2013 09:46, MK wrote: > > > > > > .. > > >> > > >> I've been using VHDL for years (started with a 1 week course by Esperan > > >> who don't exist any more.) > > > > > > they are still alive and kicking... > > > > > > Hans > > > www.ht-lab.com > > > > > > > > > > > Well so they are - I was sure they'd gone. Perhaps I'll ask them about > > their Verilog for VHDL users course. > > > > Michael Kellett Thanks for all replies. I will read some articles and look into some open source IP cores (for learning, not for plagiarize). I decided to use FPGA because I need 4 channels QEI, 4 channels DDS and another small logic. -- PauloArticle: 155880
On 10/10/13 09:47, Svenn Are Bjerkem wrote: > I have been programming FPGA with VHDL for some years now. I came from high-speed full-custom and digital standard cell semiconductor design with cadence and that was 100% schematic capture. > > I have two books: > FPGA prototyping by VHDL examples, by Pong P. Chu > Circuit Design with VHDL, by Volnei A. Pedroni. > > Both books gave me a good introduction to the procedure of mapping something structural (schematic, block diagram) into something behavioural (RTL, FSM), and at the same time cover something I knew, real hardware. Thanks, I'll have a look. > Chu has a short tutorial on a Xilinx project to get started with the toolchain, and Pedroni has tutorials for Xilinx and Altera. I didn't follow any of these tutorials as I pretty much understood the FPGA tools by previous tool experience. I'm sure I'll figure out the toolchain basics fairly quickly, but I'm less convinced about the subtleties. I'm hoping 100 power tips for fpga designers" by Evgeni Stavinov will give me some clues. > Other than that, Xilinx has some documents on coding style, both for esthetics and for speed. Google for "xilinx coding guidelines" as they are hidden in obscure places. I've tried "xilinx style guide", but that's a useful alternative term. > The switch from schematic structural thinking to VHDL behavioural thinking sometimes lead to horrible code. The above books helped me through that period, specially regarding use of clock enable instead of gated clocks Not concerned about avoiding that trap :) > and avoid inferring unwanted latches. ...but that trap is more subtle :( > Just remember to replace the clk'event and clk='1' with the modern rising_edge(clk) in the textbook examples. I've read there are subtle differences, but I've forgotten what they are! "rising_edge(clk)" is terser. > The biggest hurdle was to accept that the synthesizer could do a better job than me and stop being too clever during design. I haven't of course, calibrated my definition of "too clever". My current presumption is that I'll use behavioural code except where I've decided I need a specific "high level" primitive provided by the device manufacturer.Article: 155881
Svenn Are Bjerkem <svenn.bjerkem@googlemail.com> wrote: (snip) > The switch from schematic structural thinking to VHDL behavioural > thinking sometimes lead to horrible code. The above books helped > me through that period, specially regarding use of clock enable > instead of gated clocks and avoid inferring unwanted latches. > Just remember to replace the clk'event and clk='1' with the > modern rising_edge(clk) in the textbook examples. I mostly write structural verilog, though behavioral for FFs (the only way I know) and usually behavioral for state machines. > The biggest hurdle was to accept that the synthesizer could do > a better job than me and stop being too clever during design. Yes, this one I agree with. Though they don't find everything, there are many cases where they can do well with more obvious, and not so efficient looking, code. -- glenArticle: 155882
Dear all, I fear that I have an issue with reset time propagation all over my design and this may cause unknown initial conditions after reset. We have a pll and we use the 'lock' signal as a global reset, in this way we guarantee that flops are coming out of reset with a fully running clock. My question here is the following: should I route the 'lock' signal to a special buffer to minimize delays or would it be sufficient to use it as is? Thanks a lot, Al p.s.: I'm using Actel Igloo. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 155883
In article <bbq71aFcrddU1@mid.individual.net>, alb <alessandro.basili@cern.ch> wrote: > >I fear that I have an issue with reset time propagation all over my >design and this may cause unknown initial conditions after reset. > >We have a pll and we use the 'lock' signal as a global reset, in this >way we guarantee that flops are coming out of reset with a fully running >clock. > >My question here is the following: should I route the 'lock' signal to a >special buffer to minimize delays or would it be sufficient to use it as is? Not familiar with Igloo family, so can't offer specific advice, but I do have general advice on the "lock" signal coming out of PLLs. These signals are notoriously unreliable from many families. They tend to "chatter" going into lock (i.e. indicating a lock, then falling out of lock, then back in). This all, of course, can vary by design. But I now almost always take the tact of casting a suspicicious eye on a PLL's lock indicator, and usually qualify it with something else rather than using it raw. Often, I just take the data sheet "max lock time" spec. I wait for this time to pass, AND the lock signal to indicate true before truly declaring lock. Your mileage may vary - and as I said, I'm not familiar with the igloo family, so don't know its PLL design at all. But my experience with PLLs here is from many various designs, in many various technologies (ASICs at various nodes/various FPGAs). The second piece of advice I can offer is to have your STA tool check the timing. You should synchronize your reset, then treat it like any other signal that's timing checked - you'll know quickly whether or not you'll need to treat that high-fanout net with special handing. Regards, MarkArticle: 155884
alb <alessandro.basili@cern.ch> wrote: > I fear that I have an issue with reset time propagation all over my > design and this may cause unknown initial conditions after reset. > We have a pll and we use the 'lock' signal as a global reset, in this > way we guarantee that flops are coming out of reset with a fully > running clock. > My question here is the following: should I route the 'lock' > signal to a special buffer to minimize delays or would it be > sufficient to use it as is? First, I agree with what Mark says. In addition, note that most FPGA families have a global reset line similar to the global clock lines. They usually keep all the FF held at reset until configuration is done, and also allow you to use that reset line. It is there, it is free, and you might was well use it. You do still have to get the timing right, so you release it at the right time relative to the clock edge. -- glenArticle: 155885
In article <l39dsb$4q1$1@speranza.aioe.org>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>First, I agree with what Mark says.
>In addition, note that most FPGA families have a global reset line
>similar to the global clock lines. They usually keep all the FF held
>at reset until configuration is done, and also allow you to use that
>reset line. It is there, it is free, and you might was well use it.
>You do still have to get the timing right, so you release it at
>the right time relative to the clock edge.
The timing provided by the global reset line is not good.. it's nowhere near
as good as a global clock line as far as I understand.
One way to deal with this is to have all of your state machines start in a
reset state which does nothing but wait for a synchronous "start" edge which
is generated after reset with a counter or a shift register.
This has a big advantage that you no longer have to worry about global reset
timing. On the other hand, if you use libraries you may have no choice
since you can't change the logic.
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 155886
Do any of the vendors provide a way to use the global reset net, but avoid
having to tie it to a pin. In other words:
module top
(
in,
q
);
wire clk;
wire reset_l;
internal_clock_generator osc (.clk(clk)); // Some chips have this
internal_reset_generator rst (.reset_l (reset_l)); // None have this I think
always @(posedge clk or negedge reset_l)
if (!reset_l)
q <= 1; // Initial state is 1, not 0!
else
q <= in;
The answer used to be no, but maybe things have changed..
Yes, I know the global reset will reset everything anyway, but you need a
reset net for the synthesizer to infer the initial state. If you tie the
reset net to a constant, it gets optimized out.
Yes, I also know that the vendors provide ways of triggering the global
reset net from a pin by connecting it to the 'GSR' module.
I guess one way it make a black box hard macro which does nothing and tie it
to the fake reset net.
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 155887Hi Mark, On 11/10/2013 18:46, Mark Curry wrote: [] >> My question here is the following: should I route the 'lock' signal to a >> special buffer to minimize delays or would it be sufficient to use it as is? [] > These signals are notoriously unreliable from many families. They > tend to "chatter" going into lock (i.e. indicating a lock, then falling > out of lock, then back in). This all, of course, can vary by design. > But I now almost always take the tact of casting a suspicicious > eye on a PLL's lock indicator, and usually qualify it with something > else rather than using it raw. > That's a big hint! In the past I typically had a 'powerup reset' done with an external RC line with a big time constant, enough to allow the clock to be stable. The current design I'm working on had already been written and I thought the idea of using the internal pll lock signal was not too bad, but I was not aware of these reliability issues. That might explain why every third power up nothing works! > Often, I just take the data sheet "max lock time" spec. I wait > for this time to pass, AND the lock signal to indicate true before > truly declaring lock. Uhm... and how do you reset the counter you need to rely on? Certainly I can use the 'not lock' signal to keep the counter reset and then add the extra margin. > Your mileage may vary - and as I said, I'm not familiar with the igloo > family, so don't know its PLL design at all. But my experience > with PLLs here is from many various designs, in many various technologies > (ASICs at various nodes/various FPGAs). Since I do not have any experience with this strategy at all I guess that your point is already discouraging enough to continue stubbornly along this path. I'll try the 'max lock time' approach and see what it leads to. > > The second piece of advice I can offer is to have your STA tool check > the timing. You should synchronize your reset, then treat it like > any other signal that's timing checked - you'll know quickly > whether or not you'll need to treat that high-fanout net with special > handing. Checked and found timing violations. Fan-out is ~400. I've seen in the past reset signals routed through a clockbuffer, is this a wise move?Article: 155888
Hi Glen, On 11/10/2013 19:52, glen herrmannsfeldt wrote: [] >> My question here is the following: should I route the 'lock' >> signal to a special buffer to minimize delays or would it be >> sufficient to use it as is? > > First, I agree with what Mark says. and I also start to believe my reset strategy is weak! > In addition, note that most FPGA families have a global reset line > similar to the global clock lines. They usually keep all the FF held > at reset until configuration is done, and also allow you to use that > reset line. It is there, it is free, and you might was well use it. Apparently I have not found a 'global reset line' for the igloo family, but there's an interesting application note from Actel/Microsemi on their Flash-based devices which I find quite interesting: http://www.actel.com/documents/LPF_AC380_AN.pdf It boils down to exploiting the difference in power up between input buffer and output buffer, therefore leading to the possibility to drive two states for an active/deactive reset. In the AN it refers to the possibility to extend the reset line with a counter which is 'preset' by the Power-on Reset (POR), potentially useful to wait for external circuitry to reach to an operational state before the FPGA logic starts. It's unfortunate that in my case I do not have an unused pulled-up pin and I'm wondering whether I can use the same technique profiting of the 'weak pull-up' capabilities that can be programmed in the I/O. From this AN: http://www.eettaiwan.com/STATIC/PDF/200811/20081121_Actel_AN03.pdf?SOURCES=DOWNLOAD it seems that 'weak pull-up/down' will be activated as soon as Vcc and Vcci are above functional threshold, which is essentially enough to have a logic '1' driven at the input of the POR proposed in the other note. > > You do still have to get the timing right, so you release it at > the right time relative to the clock edge. This is something I typically do. I keep a couple, if not more, of clock tics to deactivate the reset. This makes the reset signal like any other one and no special time constraints are needed.Article: 155889
In article <bbr63nFjeruU1@mid.individual.net>, alb <alessandro.basili@cern.ch> wrote: >Hi Mark, > >On 11/10/2013 18:46, Mark Curry wrote: >[] >>> My question here is the following: should I route the 'lock' signal to a >>> special buffer to minimize delays or would it be sufficient to use it as >>> is? >[] >> These signals are notoriously unreliable from many families. They >> tend to "chatter" going into lock (i.e. indicating a lock, then falling >> out of lock, then back in). This all, of course, can vary by design. >> But I now almost always take the tact of casting a suspicicious >> eye on a PLL's lock indicator, and usually qualify it with something >> else rather than using it raw. >> > >That's a big hint! In the past I typically had a 'powerup reset' done >with an external RC line with a big time constant, enough to allow the >clock to be stable. The current design I'm working on had already been >written and I thought the idea of using the internal pll lock signal was >not too bad, but I was not aware of these reliability issues. > >That might explain why every third power up nothing works! > >> Often, I just take the data sheet "max lock time" spec. I wait >> for this time to pass, AND the lock signal to indicate true before >> truly declaring lock. > >Uhm... and how do you reset the counter you need to rely on? Certainly I >can use the 'not lock' signal to keep the counter reset and then add the >extra margin. The counter needs to explictly NOT be connected to "lock" at all. The counter should be initialized whenever the PLL begins it's acquisition. If no explicit reset pin exists, then device init? You need a one shot or something at end of config. Check docs for Igloo - like I said, I'm not familiar with the family. Xilinx let you use init values for this i.e.: reg one_shot = 1; always @( posedge clk ) one_shot <= 0; Would create a one cycle high pulse after init. Modify as needed for more than one cycle high. >> >> The second piece of advice I can offer is to have your STA tool check >> the timing. You should synchronize your reset, then treat it like >> any other signal that's timing checked - you'll know quickly >> whether or not you'll need to treat that high-fanout net with special >> handing. > >Checked and found timing violations. Fan-out is ~400. I've seen in the >past reset signals routed through a clockbuffer, is this a wise move? Depends on FPGA architecture. I believe in Xilinx this wouldn't work, as the clockbuffer only routes to clocks, not data pins (or resets). Replicate the source FF maybe? Can you have the tools do this for you? i.e. create your qualified lock. Pipeline delay it a few cycles, then let the tool replicate the final stage as much as neccesary. Depends on the synthesis/PAR tools. Regards MarkArticle: 155890
Did you solve it??Article: 155891
hello, did u get an answer for this? I also have the same issue.I am using ModelSim PE Student Edition 10.2c.I am not able to see the changes in instantiated moduleArticle: 155892
On 10/11/2013 5:46 PM, alb wrote: > Hi Glen, > > On 11/10/2013 19:52, glen herrmannsfeldt wrote: > [] >>> My question here is the following: should I route the 'lock' >>> signal to a special buffer to minimize delays or would it be >>> sufficient to use it as is? >> >> First, I agree with what Mark says. > > and I also start to believe my reset strategy is weak! > >> In addition, note that most FPGA families have a global reset line >> similar to the global clock lines. They usually keep all the FF held >> at reset until configuration is done, and also allow you to use that >> reset line. It is there, it is free, and you might was well use it. > > Apparently I have not found a 'global reset line' for the igloo family, > but there's an interesting application note from Actel/Microsemi on > their Flash-based devices which I find quite interesting: > > http://www.actel.com/documents/LPF_AC380_AN.pdf Wow, if Actel doesn't have a global reset line I have no idea how they make their parts work. I haven't read the above app note, but the way most brands of FPGAs work, there is a global reset line which holds the user logic in reset until the end of config. This like is similar to a global clock line, but without the high speed drive. When the reset is released the entire chip can start. The problem is the delay on this line is long enough to cause problems releasing the entire design on the same clock cycle. It is seldom that an entire FPGA design has to start on the same clock edge. I design individual circuits to start up on a local copy of the reset. Or better still is to design them so they start in an idle state waiting for something else to happen which will take a clock cycle or two providing enough delay that they don't need a synchronous reset. > It boils down to exploiting the difference in power up between input > buffer and output buffer, therefore leading to the possibility to drive > two states for an active/deactive reset. > > In the AN it refers to the possibility to extend the reset line with a > counter which is 'preset' by the Power-on Reset (POR), potentially > useful to wait for external circuitry to reach to an operational state > before the FPGA logic starts. > > It's unfortunate that in my case I do not have an unused pulled-up pin > and I'm wondering whether I can use the same technique profiting of the > 'weak pull-up' capabilities that can be programmed in the I/O. From this AN: > > http://www.eettaiwan.com/STATIC/PDF/200811/20081121_Actel_AN03.pdf?SOURCES=DOWNLOAD > > it seems that 'weak pull-up/down' will be activated as soon as Vcc and > Vcci are above functional threshold, which is essentially enough to have > a logic '1' driven at the input of the POR proposed in the other note. Are you saying you have designed the board without consideration to resetting the FPGA? I can't imagine the Actel parts require an external reset. I'm glad I am finding this out now. >> You do still have to get the timing right, so you release it at >> the right time relative to the clock edge. > > This is something I typically do. I keep a couple, if not more, of clock > tics to deactivate the reset. This makes the reset signal like any other > one and no special time constraints are needed. Yes. -- RickArticle: 155893
On 10/11/2013 4:06 PM, Joseph H Allen wrote: > Do any of the vendors provide a way to use the global reset net, but avoid > having to tie it to a pin. In other words: > > module top > ( > in, > q > ); > > wire clk; > wire reset_l; > > internal_clock_generator osc (.clk(clk)); // Some chips have this > > internal_reset_generator rst (.reset_l (reset_l)); // None have this I think > > always @(posedge clk or negedge reset_l) > if (!reset_l) > q <= 1; // Initial state is 1, not 0! > else > q <= in; > > The answer used to be no, but maybe things have changed.. > > Yes, I know the global reset will reset everything anyway, but you need a > reset net for the synthesizer to infer the initial state. If you tie the > reset net to a constant, it gets optimized out. > > Yes, I also know that the vendors provide ways of triggering the global > reset net from a pin by connecting it to the 'GSR' module. > > I guess one way it make a black box hard macro which does nothing and tie it > to the fake reset net. > At least for Xilinx you don't "connect" the GSR net unless you use the STARTUP module. Normally an explicit reset net, whether supplied by a pin or from internal logic, uses general routing. If you can live without this, XST will synthesis initial values in register declarations like: reg [3:0] foo = 4'd7; It also properly synthesizes initial blocks for initializing registers or arrays, including $readmemh or $readmemb. For lower level modules, you can use an asynchronous reset term in all your synchronous always blocks and tie that reset to a port, then ground it (or tie high if you like active low reset) at the instantiation. Then the resets will be trimmed during map, but XST still infers the proper initial state for global reset. In all the years I've used Xilinx tools and FPGA's I don't think I ever actually assigned a package pin for a reset, although I typically have an internally generated reset net using a short shift register that initializes to all ones and shifts in zero after power-up. -- GaborArticle: 155894
On 2013-10-13 03:18:43 +0000, rickman said: > On 10/11/2013 5:46 PM, alb wrote: >> Hi Glen, >> >> On 11/10/2013 19:52, glen herrmannsfeldt wrote: >> [] >>>> My question here is the following: should I route the 'lock' >>>> signal to a special buffer to minimize delays or would it be >>>> sufficient to use it as is? >>> >>> First, I agree with what Mark says. >> >> and I also start to believe my reset strategy is weak! >> >>> In addition, note that most FPGA families have a global reset line >>> similar to the global clock lines. They usually keep all the FF held >>> at reset until configuration is done, and also allow you to use that >>> reset line. It is there, it is free, and you might was well use it. >> >> Apparently I have not found a 'global reset line' for the igloo family, >> but there's an interesting application note from Actel/Microsemi on >> their Flash-based devices which I find quite interesting: >> >> http://www.actel.com/documents/LPF_AC380_AN.pdf > > Wow, if Actel doesn't have a global reset line I have no idea how they > make their parts work. I haven't read the above app note, but the way > most brands of FPGAs work, there is a global reset line which holds the > user logic in reset until the end of config. This like is similar to a > global clock line, but without the high speed drive. When the reset is > released the entire chip can start. The problem is the delay on this > line is long enough to cause problems releasing the entire design on > the same clock cycle. Actel/Microsemi FPGAs are FLASH so don't need configuration. You have to reset them in the same way you would an ASIC. > > It is seldom that an entire FPGA design has to start on the same clock > edge. I design individual circuits to start up on a local copy of the > reset. Or better still is to design them so they start in an idle > state waiting for something else to happen which will take a clock > cycle or two providing enough delay that they don't need a synchronous > reset. Designing for all-IDLE FSMs is the proper approach but doesn't eliminate the need to have an explicit reset. Global resources are typically used for the RESET even when timing is not an issue to remove the routing burden of thousands of loads. The locally copied RESETs are usually only useful if you need to support synchronous resets. > > >> It boils down to exploiting the difference in power up between input >> buffer and output buffer, therefore leading to the possibility to drive >> two states for an active/deactive reset. >> >> In the AN it refers to the possibility to extend the reset line with a >> counter which is 'preset' by the Power-on Reset (POR), potentially >> useful to wait for external circuitry to reach to an operational state >> before the FPGA logic starts. >> >> It's unfortunate that in my case I do not have an unused pulled-up pin >> and I'm wondering whether I can use the same technique profiting of the >> 'weak pull-up' capabilities that can be programmed in the I/O. From this AN: >> >> http://www.eettaiwan.com/STATIC/PDF/200811/20081121_Actel_AN03.pdf?SOURCES=DOWNLOAD >> >> >> it seems that 'weak pull-up/down' will be activated as soon as Vcc and >> Vcci are above functional threshold, which is essentially enough to have >> a logic '1' driven at the input of the POR proposed in the other note. > > Are you saying you have designed the board without consideration to > resetting the FPGA? I can't imagine the Actel parts require an > external reset. I'm glad I am finding this out now. > > >>> You do still have to get the timing right, so you release it at >>> the right time relative to the clock edge. >> >> This is something I typically do. I keep a couple, if not more, of clock >> tics to deactivate the reset. This makes the reset signal like any other >> one and no special time constraints are needed. > > Yes.Article: 155895
In article <l3d4aa$dmi$1@dont-email.me>, Gabor <gabor@szakacs.org> wrote:
>reg [3:0] foo = 4'd7;
Yeah I've been playing with this, it does work, but has the disadvantage
that your code will then be different from RTL for an ASIC.. I mean if you
used these initial values for all flops in the design, then you would not
need an explicit reset net at all. I'm pretty sure design compiler will not
support it.
>In all the years I've used Xilinx tools and FPGA's I don't think
>I ever actually assigned a package pin for a reset, although I
>typically have an internally generated reset net using a short
>shift register that initializes to all ones and shifts in zero
>after power-up.
This means you will not be able to use the FPGA's already existing global
reset net in place of one which takes up routing resources. This one shift
register will prevent you from making the explicit reset net equal to the
built-in one (which only works if all flops in the entire design are
connected to the same net).
Anyway, it's not such a big deal with the chips these days, but still it
would be nice if there was a way to do it. The initial value is a good way
to make an internal reset generator as you say.
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 1558962013=EB=85=84 4=EC=9B=94 5=EC=9D=BC =EA=B8=88=EC=9A=94=EC=9D=BC =EC=98=A4= =EC=A0=84 7=EC=8B=9C 20=EB=B6=84 9=EC=B4=88 UTC+9, Mike Butts =EB=8B=98=EC= =9D=98 =EB=A7=90: > Hi Paul, >=20 >=20 >=20 > It's a plain XC3020. I installed a 2001 Student Edition on my Win7 machin= e, and it appears to run. All it needed was the license code that came with= the CD-ROM.=20 >=20 >=20 >=20 > I'm pretty sure XC3020 and XC3020A differ only in timing and the same bit= file can work on both. Anyway I'll be finding out sometime soon and I'll po= st how it goes.=20 >=20 > Thanks all! >=20 >=20 >=20 > --Mike Hi Mike, Do you have any progress? I am very interesting your work...^^ Thanks. Wayne HwangArticle: 155897
Hello all, I have been using Vivado HLS to create an IP to later use the rest of the t= oolflow to implement a system using a Microblaze and the HLS IP. HLS actaul= ly automatically creates drivers for programming the system and controlling= it through the Microblaze.I need to use this tooflow since i onyl have a v= irtex 7 available and use 7-series only xilinx IPs. So to go by the old EDK= flow is not an option.=20 These are supposed to be imported in SDK. the problem is that SDK do not re= cognize the drivers and as such the IP in SDK is defined as having generic = driver instead if its own. I did change the repository to point at the HLS = drivers but still i do not get the option to use the HLS driver.=20 I am thinking that it is a naming issue...My IP's name is ComputeNetwork. W= hat I see is that in the MDD files the HLS IP adds in the naming of the sup= ported peripherals version stuff... http://img826.imageshack.us/img826/3314/1yl2.png Yet the IDE and SDK see my IP just as a ComputeNetwork component: http://img197.imageshack.us/img197/1047/4nmf.png http://img62.imageshack.us/img62/5428/2fwx.png Did not get any answers in the xilinx forum...Any ideas about the issue wil= l be greatly appreciated. Thanks a lot, GeorgeArticle: 155898
Joseph H Allen wrote: > In article <l3d4aa$dmi$1@dont-email.me>, Gabor <gabor@szakacs.org> wrote: > >> reg [3:0] foo = 4'd7; > > Yeah I've been playing with this, it does work, but has the disadvantage > that your code will then be different from RTL for an ASIC.. I mean if you > used these initial values for all flops in the design, then you would not > need an explicit reset net at all. I'm pretty sure design compiler will not > support it. > >> In all the years I've used Xilinx tools and FPGA's I don't think >> I ever actually assigned a package pin for a reset, although I >> typically have an internally generated reset net using a short >> shift register that initializes to all ones and shifts in zero >> after power-up. > > This means you will not be able to use the FPGA's already existing global > reset net in place of one which takes up routing resources. This one shift > register will prevent you from making the explicit reset net equal to the > built-in one (which only works if all flops in the entire design are > connected to the same net). > > Anyway, it's not such a big deal with the chips these days, but still it > would be nice if there was a way to do it. The initial value is a good way > to make an internal reset generator as you say. Now that I think of it, Lattice has a way to use the global reset net internally. At least in the last parts I used (ECP and ECP2) you could do essentially the same business I did with Xilinx, and then tie the output of the shift register to the global reset net. The reason this works in Lattice and not Xiinx is that the Lattice parts allow you to remove the global reset function on a flop-by-flop basis. Thus you turn off global reset on the reset S/R itself. As for Xilinx and routing resources, initial values take no routing resources because they just happen during configuration. Earlier Xilinx FPGA's had no dedicated global reset net. i.e. if you used a pin as a "global" reset, it still got routed using the general fabric routing. The "GSR" was actually implemented as a global write enable that holds off changes in all registers (including SRL and BRAM) until the end of configuration. Only newer families have a STARTUP primitive that allows you to re-assert the global reset. Still, you end up needing to be careful when using the global reset for startup as its skew over the part is very large. Thus you may need more than one startup state on a state machine to be sure all flops in the part are out of reset before you get to any state that depends on external (to the FSM) signals. -- GaborArticle: 155899
In article <l3gq1p$ua8$1@dont-email.me>,
GaborSzakacs <gabor@alacron.com> wrote:
>Joseph H Allen wrote:
>> In article <l3d4aa$dmi$1@dont-email.me>, Gabor <gabor@szakacs.org> wrote:
>>> reg [3:0] foo = 4'd7;
>> Yeah I've been playing with this, it does work, but has the disadvantage
>> that your code will then be different from RTL for an ASIC.. I mean if you
>> used these initial values for all flops in the design, then you would not
>> need an explicit reset net at all. I'm pretty sure design compiler will not
>> support it.
BTW, this syntax works for Synplify, but not for Lattice's new LSE.
Also I discovered that switching between synthesis tools breaks the pin
assignments.
>>> In all the years I've used Xilinx tools and FPGA's I don't think
>>> I ever actually assigned a package pin for a reset, although I
>>> typically have an internally generated reset net using a short
>>> shift register that initializes to all ones and shifts in zero
>>> after power-up.
>> This means you will not be able to use the FPGA's already existing global
>> reset net in place of one which takes up routing resources. This one shift
>> register will prevent you from making the explicit reset net equal to the
>> built-in one (which only works if all flops in the entire design are
>> connected to the same net).
>> Anyway, it's not such a big deal with the chips these days, but still it
>> would be nice if there was a way to do it. The initial value is a good way
>> to make an internal reset generator as you say.
>Now that I think of it, Lattice has a way to use the global reset net
>internally. At least in the last parts I used (ECP and ECP2) you could
>do essentially the same business I did with Xilinx, and then tie the
>output of the shift register to the global reset net. The reason this
>works in Lattice and not Xiinx is that the Lattice parts allow you to
>remove the global reset function on a flop-by-flop basis. Thus you
>turn off global reset on the reset S/R itself.
I found the part of Lattice's documentation which talks about this- it's
quite elborate (complex). It looks like the default is to use GSR for the
largest reset net, and disable it for any others. I'm surprised that they
found it worthwhile to add this configuration bit to every flop in the chip.
I wonder if flops with GSR disabled are really in an indeterminate state out
of configuration... I guess it could be either way: if they clear the config
bit chain and hit the global reset before loading the design they would get
cleared..
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
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