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
-- Creates an ERROR:Place:645 if UCF file LOCs pins to non clock inputs -- cam1_xclk_ibufd_inst : IBUFDS -- port map ( -- O => cam1_xclk, -- to DCM input -- I => gpio_exp_hdr2(7), -- IB => gpio_exp_hdr2(6) ); -- This code didn't help the ERROR:Place:645 / WARNING:Place:644 problem -- Does improve the route if one moves the pins to a clock input -- cam1_xclk_ibufgds_inst : IBUFGDS -- generic map ( -- -- DIFF_TERM => "FALSE", -- Differential Termination (Virtex-4 only) -- -- Above line created a TYPE error -- -- Language Template differs from v4ldl libraries guide. -- -- IBUF_DELAY_VALUE => "0", -- -- Specify the amount of added input delay for buffer, -- -- "0"-"16" (Spartan-3E only) -- IOSTANDARD => "DEFAULT") -- port map ( -- O => cam1_xclk, -- I => gpio_exp_hdr2(7), -- IB => gpio_exp_hdr2(6)); -- This code does not get rid of WARNING:Place:644 but -- does improve the appearance of the internal clock route -- even though the UCF file has the pins LOC to non clock inputs cam1_xclk_ibufd_inst : IBUFDS port map ( O => cam1_xclk_intermediate, I => gpio_exp_hdr2(7), IB => gpio_exp_hdr2(6) ); cam1_xclk_bufg : BUFG port map ( O => cam1_xclk, -- to DCM input I => cam1_xclk_intermediate ); Brad Smallridge aivision.comArticle: 92001
Austin, I have to disagree with you about most designs being done with fpgas and there being loads of jobs in the market. I fairly recently graduated from school with a computer engineering degree. I did a lot of FPGA work while I was in school using both Xilinx and Altera platform (as for the X vs. A debate, I'm agnostic, I find Xilinx's tools to be more complete, but I find Altera's GUI to be nicer). Despite doing all of that FPGA work I did not find a single job having anything to do with FPGAs. However, I worked for an ASIC company that was not on your list and now I work for a different ASIC company. I get the impression that ASICs are still very popular despite their rising NRE costs. All that said, I do recommend looking at all the FPGA stuff you can. Regardless of whether you go into ASICs or FPGAs in your career, FPGA development will give you a *GREAT* background. I might even go so far as to say that FPGA development will give you a better modern digital design background that most of the old-timer engineers have. My experience has been that FPGAs teach all of the fundamentals: * basic logic design * static timing * hand optimization to meet timing A couple of things are skipped like: * electromigration * cross-talk * voltage-domain crossing But really FPGAs offer most of what you need. The really big thing that they do that many of the "old-timers" don't get is they force you to reduce the number of clock domains you have. FPGAs have a very limited number of global clock nets. As a result you learn that it's best to not generate a clock for every single flip flop that's driven or to put HUGE amounts of logic in a clock net or to do loads of async design. This is a great thing to get used to since modern ASIC and FPGA flows do not adapt well to this. I might also add that when you're looking at internships and first jobs that it's best not to expect to do exactly what you want. You can ask around to all of your profs to see if they have contacts, but my experience has been that it is generally not the case. My profs seemed to like to avoid FPGAs like the plague and generally thought that digital design was for the weak (or something since they did a pretty lousy job of teaching it in my opinion). Good luck. Also, don't be afraid to apply for jobs that you're under-qualified for. A lot of companies put up requirements that are completely outlandish hoping for a miracle, but expecting much less. If a job says 5 years experience required. Go ahead. Apply for it! -ArlenArticle: 92002
To get a good idea of the type of applications that Cyclone II /Cyclone devices are used in check the following link: http://www.altera.com/corporate/cust_successes/customer_showcase/view_product/csh-vproduct-cyclone.jsp The use of these devices in an application is only limited by your imagination. Remember you can have your own NiosII processor running on these chips, to allow you greater flexibility and creativity. In a student competition sponsored by Altera, one of the winners implemented a biometric system running on a Cyclone chip using the UP3 board. Happy experimentation, Subroto Datta Altera Corp. "badgrant" <badgrant@yahoo-dot-com.no-spam.invalid> wrote in message news:V5idnQ62EdUrBuDeRVn_vA@giganews.com... > hi, i'm grant, studying computer engineering in university of ottawa. > i'm using altera cyclone II on up3 board with quartus II enviorment. > how is it? is it leading in industry? what kind of job can i get when > i'm done. > > guys, forgive me if i have tons of questions, coz i do care about my > career while i know nothing about it right now. :p >Article: 92003
Hi, We need to evaluate new CLB architectures for routing area and delay. In VPR how can I specify my CLB architecture accurately. In architecture file all I could find out was that we can change number of LUTs and their input size. But in our architectures apart from LUTs we also have some extra combinational modules. Is it possible for me to specify no of transistors that my CLB takes in VPR and then let VPR do placement and routing because that will give routing area and delay according to our architecture. If yes where should I do that. I feel that currently VPR finds out number of transistors of a CLB based on number of LUTs present but I was unable to figure out where does it use this information after going through the code. Kindly help me if someone has gone through the code or has modified it. Thanks and regards,Article: 92004
Important if you need your designs to cleanly reset every time.
Apologies, but many folks are still posting code for asynchronous
resets... some are even advocating it:
On Nov 11, over in thread "Open Source FPGA...", Mike Treseler wrote:
"I use exactly this template of three top procedures in every new
design entity:
begin -- process template
if reset = '1' then
init_all_regs; -- no port init required
elsif rising_edge(clock) then
update_process_regs;
end if;
update_output_ports; -- wires ok for reset or clk
end process template;
"
This is only the most recent example, and seeing this asynchronous
reset code over and over again is starting to worry me, particulary
considering that some FPGA's may be in critical environments, where
cleanly coming out of reset is vital.
Xilinx[Ken Chapman] suggests this is not the most efficient strategy
for LUT utilization in http://tinyurl.com/66xby. Ken cheats a bit in
his article (he re-works an async reset to be sync to get a more
compact circuit, but the behavior of the smaller circuit is different
than the original!), but overall he has a good point. And there is a
stronger reason to write your code to reset synchronously. The
following is quoted verbatim from the Xilinx Constraints Guide
(cgd.pdf), in the Timing Constraints section:
"The tools do not automatically analyze asynchronous set/reset paths."
(I assume tools means Map/Place/Route)
This bears repeating.
"The tools do not automatically analyze asynchronous set/reset paths."
Following that scary statement is a reference to the "Enable" and
"Disable" constraints, which control timing checks over these two paths
(among others):
"Asynchronous Set/Reset to output propagation delay"
and
"Synchronous Set/Reset to clock setup and hold checks"
But lo and behold! There is NO checking (according to cgd above) of the
path:
"Asynchronous Set/Reset to clock setup and hold checks"
(I like the convention of calling "async reset" clear, and calling
"async set" preset, leaving set/reset for the sync functions, and will
try to stick with that for the rest of this discussion)
The clear pin may be released at various registers in a process with
uncertain timing relative to clock, _even_ if the clear signal started
out synchronous. This has the same potential for trouble as any other
async input to a synchronous state machine, because clear is just
another input after all. A one-hot state machine can go no-hot or
many-hot; a binary coded (non-Gray) SM may enter an illegal state; or
see Ray's counter example (which is _not_ a counter-example) at
http://tinyurl.com/8gjxe. These are not good things.
I've modified my style to ALWAYS reset synchronously, using a sync
reset (with considered exceptions for certain unique circuits):
process(clock)
begin
if RISING_EDGE(clock) then
if reset = '1' then
init_regs; -- the ones that need it.
else
[elsif enable = '1' then] -- I like this form, it's free
update_process_regs;
end if; end if;
end process;
Sure, it means that reset has to be synchronized somewhere, and (egad,
worse yet!) typing an extra "end if" and indenting a level deeper, but
this is a small price to pay for designs that start up first time,
every time.
To quote Ray:
" Generally speaking, asynchronous resets are a very bad idea in
FPGAs."
Because this might be mis-interpreted, I'd clarify that and say even
synchronous resets, if used as a clear function, are a bad idea. Write
code to reset synchronously. Keep clear of that clear pin.
Regards to all,
John
Article: 92005"JustJohn" <john.l.smith@titan.com> schrieb im Newsbeitrag news:1132397821.560864.109950@g49g2000cwa.googlegroups.com... > > On Nov 11, over in thread "Open Source FPGA...", Mike Treseler wrote: > > "I use exactly this template of three top procedures in every new > design entity: > > begin -- process template > if reset = '1' then > init_all_regs; -- no port init required > elsif rising_edge(clock) then > update_process_regs; > end if; > update_output_ports; -- wires ok for reset or clk > end process template; > " Do you want to take the fun out of the world of electronic design ? > This is only the most recent example, and seeing this asynchronous > reset code over and over again is starting to worry me, particulary > considering that some FPGA's may be in critical environments, where > cleanly coming out of reset is vital. Our evolution is try and error. Do you want to hinder our evolution ? Do you want to take the exitement out of our lives ? And Frankly, every modern (since the Wintel revolution) user of any electronic device will "reboot" it until it works without worrying. I've already adapted this behaviour subconsciously. I also experience a much higher rate of failure during operation of electronic devices. Raymund HofmannArticle: 92006
JustJohn wrote: > "The tools do not automatically analyze asynchronous set/reset paths." > (I assume tools means Map/Place/Route) > > This bears repeating. > "The tools do not automatically analyze asynchronous set/reset paths." You can turn this on the UCF. Every UCF I have ever written has contained the lines: # magic incantation to make the tools trace timing through reset paths ENABLE= reg_sr_q; Regards, AllanArticle: 92007
Hello, in my project I have 20 boards with an Altera Stratix II EP2S60 FPGA. When configuring and operating at room temperature (e.g. around 20 deg C), everthing works as expected. When configuring at room temperature and raising the operating temperature to 70=B0 (I have the temp sensing diode connected in the FPGA and can measure the FPGA temperature), still everythings works as it should. The problems start, when configuring at higher temperatures. From my 20 boards, I tested 17 for this behaviour: 5 FPGAs are ok up to maximum tested temperature of 70=B0C 6 FPGAs fail between 60..70=B0C 2 FPGAs fail between 50..60=B0C 1 FPGA fails between 45..50=B0C 3 FPGAs fail below 45=B0C One obvious failure I observe are output pins which are set to GND in the design - no other logic driving them. The output pin is pulled high with a 10k resistor. When ok, the output signal is of course low. When failing, the output pins are floating, which results in the signal being pulled high by the pull-up resistor. A second, more difficult to observe failure case is internal. I have a PCI interface with plain old 32bit, 33MHz. When ok, the software driver reads internal registers with valid values. During failure cases, some registers are not determined. As I started, when the configuration was done at room temperature, everyting is ok, even if temperature rises to 70 deg C. I observed the power supplies 1.2V (core) and 3.3V (I/O), they are solid ok, no dropouts detectable with a scope. The board is an 18 layer PCB with of course dedicated power planes and good bypassing. In the tests it did not matter, how the FPGA was configured; JTAG or passive parallel. Both method had the same results. Has anybody observed something like this before or can give hints, where I could at? Thanks a lot in advance, HenningArticle: 92008
JustJohn wrote: > Important if you need your designs to cleanly reset every time. > > Apologies, but many folks are still posting code for asynchronous > resets... some are even advocating it: > > On Nov 11, over in thread "Open Source FPGA...", Mike Treseler wrote: > > "I use exactly this template of three top procedures in every new > design entity: > > begin -- process template > if reset = '1' then > init_all_regs; -- no port init required > elsif rising_edge(clock) then > update_process_regs; > end if; > update_output_ports; -- wires ok for reset or clk > end process template; > " > This is only the most recent example, and seeing this asynchronous > reset code over and over again is starting to worry me, particulary > considering that some FPGA's may be in critical environments, where > cleanly coming out of reset is vital. > Without seeing the rest of Mike's code, I would be willing to bet that "reset" is in fact the Xilinx power on reset. This reset is going to happen in the actual hardware asynchronously whether you like it or not. All Mike has done (I assume) is to explicitely code the actual behavior of the builtin Xilinx hardware. This is in fact a perfectly reasonable thing to do, and I also insist on all VHDL code I control explicitly show asynchronous POR behavior, in the same way. If a particular part of the circuit needs a synchronous reset, then that is simply added to the synchronous part of the process. That is a completely separate issue from POR.Article: 92009
hi, I made a programe for block matching motion estimation.In this i have to compare the (4*4) matrics of current frame,with 18,(4*4) mtrics of search frame.each element of matrics is pixel value(containing 8 bit).In first clock cycle (1,1) element of all the matrics is going to the 19 inputs of the programe.In next clock cycle(1,2) elements of all matrics will be on the inputs.Their is 18 processing element inside the programe,each processing element getting one input from search frame and one input from data frame.data frame input is common in all processing element. so i have to give 18(search frame pixel)+1 data frame pixel in every clock cycle in my verilog programe. now for implementing this in FPGA,i m using sparta3xp200ft256,that is having 100 I/O pin,but i require more input pin. please suggest any method to reduce input pin,so that i can check it in spartan kit. How can i give test signal to spartan signal for this by using xilinx webpack7.1iArticle: 92010
This is interesting Allan... I did read the docs, that's where I quoted from. Are you saying that ENABLE= reg_sr_q; which provides timing coverage for paths including: 1) "Asynchronous Set/Reset to output propagation delay" will eventually somehow undergo a transformation into a check for paths including: 2) "Asynchronous Set/Reset to clock setup and hold checks" Because I am not talking about a reset -> output issue, This is a matter of set-up/hold. Another Enable/Disable constraint, reg_sr_clk, as listed in Tables 7-1 and 7-2, gives path checking for 3) "Synchronous Set/Reset to clock setup and hold checks" but 3) is clearly different from 2). Do you see the difference I'm suggesting? Either my reasoning is totally kaflooeey, or the Xilinx documentation is fairly misleading and should be changed to something like: Enable = reg_sr_clk; implies 4) Any (Synchronous or Asynchronous) Set/Reset to clock setup and hold It might be nice to have someone from Xilinx weigh in on this. Regards, JohnArticle: 92011
JustJohn wrote: > This bears repeating. This bears This bears This bears This bears This bears Anyway, two things: 1) Do you guarantee a power-on reset either by always asserting the reset pin or through constraints? 2) What if your system is in an environment where the clock is stopped during your reset event? Power-on states are guaranteed by the asynchronous reset. Those of us who try to keep away from async resets MUST make sure there isn't an erroneous power-up state that confuses our logic OR guarantee that everything has the synchronous reset applied before the circuit affect the rest of our system.Article: 92012
Gallen, A different story that the one I have been hearing. I am glad to hear there are still good ASIC jobs around (Xilinx has openings unfilled as well). But, I still stand by my comment that FPGA jobs are more common that ASIC jobs: in fact perhaps as much as 1000:1 more common. Consider yourself very fortunate to be doing ASIC design. Austin gallen wrote: > Austin, I have to disagree with you about most designs being done with > fpgas and there being loads of jobs in the market. I fairly recently > graduated from school with a computer engineering degree. I did a lot > of FPGA work while I was in school using both Xilinx and Altera > platform (as for the X vs. A debate, I'm agnostic, I find Xilinx's > tools to be more complete, but I find Altera's GUI to be nicer). > Despite doing all of that FPGA work I did not find a single job having > anything to do with FPGAs. However, I worked for an ASIC company that > was not on your list and now I work for a different ASIC company. I > get the impression that ASICs are still very popular despite their > rising NRE costs. > > All that said, I do recommend looking at all the FPGA stuff you can. > Regardless of whether you go into ASICs or FPGAs in your career, FPGA > development will give you a *GREAT* background. I might even go so far > as to say that FPGA development will give you a better modern digital > design background that most of the old-timer engineers have. > > My experience has been that FPGAs teach all of the fundamentals: > * basic logic design > * static timing > * hand optimization to meet timing > A couple of things are skipped like: > * electromigration > * cross-talk > * voltage-domain crossing > > But really FPGAs offer most of what you need. The really big thing > that they do that many of the "old-timers" don't get is they force you > to reduce the number of clock domains you have. FPGAs have a very > limited number of global clock nets. As a result you learn that it's > best to not generate a clock for every single flip flop that's driven > or to put HUGE amounts of logic in a clock net or to do loads of async > design. This is a great thing to get used to since modern ASIC and > FPGA flows do not adapt well to this. > > I might also add that when you're looking at internships and first jobs > that it's best not to expect to do exactly what you want. You can ask > around to all of your profs to see if they have contacts, but my > experience has been that it is generally not the case. My profs seemed > to like to avoid FPGAs like the plague and generally thought that > digital design was for the weak (or something since they did a pretty > lousy job of teaching it in my opinion). > > Good luck. Also, don't be afraid to apply for jobs that you're > under-qualified for. A lot of companies put up requirements that are > completely outlandish hoping for a miracle, but expecting much less. > If a job says 5 years experience required. Go ahead. Apply for it! > > -Arlen >Article: 92013
JustJohn wrote: > This is interesting Allan... > > I did read the docs, that's where I quoted from. Are you saying that > ENABLE= reg_sr_q; which provides timing coverage for paths including: > > 1) "Asynchronous Set/Reset to output propagation delay" > > will eventually somehow undergo a transformation into a check for paths > including: > > 2) "Asynchronous Set/Reset to clock setup and hold checks" Quite possibly. It wouldn't be the first time Xilinx software did something completely contrary to the documentation. At least reg_sr_q is mentioned in the documentation now (it wasn't always). I'm a bit confused as to why you would attempt to use async resets to implement logic functions that are better handled by synchronous resets. At least with synchronous resets you can know that the results will be reliable. If I caught any of the designers here trying to use async resets that way they would get a stern talking to. Any reasonable FPGA coding guide should strongly advise against using async resets or sets to implement logic functions. (At least for Xilinx) async resets should only be connected to one net, and that net should be connected to the reset input of a startup block. Any other usage should be illegal. You should use a well known name for that net as well. Here we use the name 'gsr'. Such guidelines are based upon studies made of non-working designs and failing projects over many years. You can ignore them at your peril. AllanArticle: 92014
John_H wrote: > This bears This bears This bears This bears This bears HA HA HA, Thanks for the smile this morning, I was up late last night when I made that post, maybe got too long winded. > 1) Do you guarantee a power-on reset either by always asserting the >reset pin or through constraints? Hmm, to answer both John and Duane, I was talking about an individual reset for an entity, that may be asserted individually to that entity, separate from others in the same design and not "globally" across the chip, as a power-on reset. Perhaps code examples here in c.a.f. can make the distinction, and generally use 'por' for power-on resets, and 'rst' for not necessarily global resets. Personally, I admit to being a little lazy, and writing code so that power-on state is irrelevant for most of the the system, except in one place where a rst event is guaranteed to be generated. That rst does the real work, and does not depend on the whether the FPGA has a por or not. >2) What if your system is in an environment where the clock is stopped >during your reset event? I'll duck this for now and say that's one of the "considered exceptions for certain unique circuits". Hey, it's Saturday morning, and a bright and sunny day here in southern California. Time to get outside.Article: 92015
Allan wrote: >I'm a bit confused as to why you would attempt to use async resets to >implement logic functions that are better handled by synchronous >resets. Apologies to you Allan, I was not trying to confuse you, and I would NOT attempt such a thing, this was exactly the point of my post! Xilinx docs say they don't check clock set-up for asynchronous reset input, and yet, time after time, people post examples of async resets, which will lead the unwary into trouble. As I said on the other thread, it's a nice day out, time for a walk...Article: 92016
JustJohn wrote: > Allan wrote: > >I'm a bit confused as to why you would attempt to use async resets to > >implement logic functions that are better handled by synchronous > >resets. > > Apologies to you Allan, I was not trying to confuse you, and I would > NOT attempt such a thing, this was exactly the point of my post! Xilinx > docs say they don't check clock set-up for asynchronous reset input, > and yet, time after time, people post examples of async resets, which > will lead the unwary into trouble. > As I said on the other thread, it's a nice day out, time for a walk... I started out using TTL parts. They (usually) didn't specify setup times of async inputs with respect to the clocks. Propagation delay (async reset -> Q) was the only timing parameter specified. (I just checked the data sheet for a SN54AHC74, it seems these parameters are specified in more contemporary devices.) I feel this is more about educating newbies than blaming Xilinx for faults in their tools. Surely schools teach ... wait, I can remember my classes (a long time ago) and they didn't even touch on this sort of thing. (I'll follow your lead and take a walk outside now.) Regards, AllanArticle: 92017
JustJohn wrote:
> Hmm, to answer both John and Duane, I was talking about an individual
> reset for an entity, that may be asserted individually to that entity,
> separate from others in the same design and not "globally" across the
> chip, as a power-on reset.
My code template assumes one global reset pulse
that occurs once, on a low-skew path,
after the fpga image has loaded.
I also assume that this pulse has a source
external to, but using the same clock as the fpga.
In my case, it comes from a cpu that loads
the binary fpga image.
I don't use vendor-specific resets
because they are vendor-specific.
The reason I use this "asynchronous" style template
is that it saves logic cells in every synthesis benchmark I have run
on both brands A and X.
In summary, I use one synchronized reset pulse,
on a low skew path to the asynch reset input
of every D-flop in the design.
I expect that this template will work for me
as long as fgpa vendors keep global routing
and asynch resets on D-flops.
I will update my code examples with these comments.
-- Mike Treseler
Article: 92018>My code template assumes one global reset pulse >that occurs once, on a low-skew path, >after the fpga image has loaded. >I also assume that this pulse has a source >external to, but using the same clock as the fpga. >In my case, it comes from a cpu that loads >the binary fpga image. Is that good enough? Don't you also need the prop time on that low-skew path to be short enough relative to your clock cycle time so that you know when it gets to your FFs? Last I checked, the global reset on most Xilinx parts was too slow to be useful in that context. I thought that consensus here was to use the global reset hardware to (asynchronously) force your state machines into a known state and then use a local FF that has been synchronized to get out of that state. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 92019
I suppose I should mention that consumer level products are often where the ASICs lie. In situations where there may only be 10s, 100s or 1000s of parts, FPGAs may be very common. My work currently gets manufactured in the 100s of millions and it contains a large analog block. It just simply isn't suited for FPGA. I could see FPGAs being big in high end space (I think Cisco uses FPGAs for its backbone class routers). I could see them in government space. I could see them in prototypes (heck, our architects use them for accellerating matlab tests). I just can't see them making much inroads into high volume consumer space. The important detail to be taken from this though is that ASICs are still very alive for very high volume work as well as high speed (multi-GHz) and analog. Best of luck to all of those students out there hunting. There is an amazing amout of interesting work to be done. Also, pay attention in your signal processing classes. That is some really important stuff. -ArlenArticle: 92020
Hi guys, I experience some problem with modeling some designs in ModelSim 5.7 XE 2/Starter trough Tcl script. I have a set of designs with corresponding testbenches, and while running simulations through eval vsim -assertfile $log_file testbench I am facing the problem that ModelSim updates files only when it is being closed. I.e. the files are created but I can access them straight after the simulation: vsim -assertfile $log_file testbench run &time quit -sim So if i run script one more time I am already able to access necessary information, but I am looking for solution to accomplish it in one go. Am I missing something (some design,project closing, or probably ModelSim settings )?? Thanks for help. -- AlexArticle: 92021
Hal Murray wrote:
> Is that good enough?
It has been in many cases.
> Don't you also need the prop time on that low-skew path
> to be short enough relative to your clock cycle time so
> that you know when it gets to your FFs?
For the trailing edge, yes.
On the board, a zero delay clock buffer
and careful distribution to all devices does
the trick. On the fpga I just have to make
sure the reset node gets one of the global nets.
> Last I checked, the global reset on most Xilinx parts
> was too slow to be useful in that context.
Yes. I don't use anyone's the built-in reset.
> I thought that consensus here was to use the global
> reset hardware to (asynchronously) force your state
> machines into a known state and then use a local
> FF that has been synchronized to get out of that state.
I don't think I'm contradicting that idea.
The asynch reset gives you a starting
point for simulation. After this, well-designed
control logic will use an idle state for
specific synchronous initialization.
-- Mike Treseler
Article: 92022
Hi,
I am designing a peripheral interface IO chip which is also the Intel
i82C55 chip. THe problem I have is I want to change a interrupt signal
INTR to '1' at the rising edge of a strobe input (STB) and then later
change INTR to '0' when the read signal (RD) arrives (at the rising
edge of RD). My VHDL code is
handshaking: process(STB, RD) is
begin
if rising_edge(STB) then
INTR <= '1';
STATUS_REG(2) <= '1';
end if;
if rising_edge(RD) then
INTR <= '0';
STATUS_REG(2) <= '0';
end if;
end process;
It seems that this is a bad synchronous design. So, how can I change
my INTR signal to respond to STB and RD signals?
Any help is highly appreciated...
THank you all
Article: 92023
(Back from my walk...)
Hal wrote:
>I thought that consensus here was to use the global
>reset hardware to (asynchronously) force your state
>machines into a known state and then use a local
>FF that has been synchronized to get out of that state.
Aaahhh, thanks Hal, _very_ nicely put, succinct and clear. (It's been a
while since those discussions, I turned 50 last month, and have been
working in the wonderful world of M$ GUI design lately, so forgive me
for forgetting).
Integrating everyone's good words with Mike's generic process template
and my desire for an entity local reset into pseudo VHDL:
process (clock, gsrout) begin
if gsrout = '1' then
init_all_regs; -- Every darn one of them
init_state_regs; -- To a 'dormant' reset state
elsif RISING_EDGE(clock) then
if reset = '1' then
init_some_regs; -- Only ones really that need it,
-- both to reduce routing req's,
-- and because it may be useful
-- to keep some values across
-- a reset event
init_state_regs2; -- To an 'awake' reset state
else -- No enable form
[elsif enable = '1' then] -- Using enable form
run_reg_logic; -- And they're off to the races
run_state_logic; -- (oops, bad word, no races here!)
end if; end if;
end process;
Signal gsrout comes from the Xilinx 'STARTBUF_arch' primitive, so that
the async device clear does not take FF pins or routing. (Mike may not
like this vendor specific stuff, see my parting question)
Googling back to June reveals a 'roller' (http://tinyurl.com/ajvtw) who
asked about _not_ using this format. Nobody answered then, but after
going through this exercise, I would say this is a fairly solid
template, don't use it at your own peril.
Ok, I'm done, except for one last question... does Altera have a
similar GSR function? (Please pardon my laziness)
Thanks all,
John
Article: 92024Chintan wrote: > Hi, > I am designing a peripheral interface IO chip which is also the Intel > i82C55 chip. THe problem I have is I want to change a interrupt signal > INTR to '1' at the rising edge of a strobe input (STB) and then later > change INTR to '0' when the read signal (RD) arrives (at the rising > edge of RD). My VHDL code is > > handshaking: process(STB, RD) is > begin > if rising_edge(STB) then > INTR <= '1'; > STATUS_REG(2) <= '1'; > end if; > > if rising_edge(RD) then > INTR <= '0'; > STATUS_REG(2) <= '0'; > end if; > > end process; > > It seems that this is a bad synchronous design. So, how can I change > my INTR signal to respond to STB and RD signals? > Any help is highly appreciated... > > THank you all > Code up an RS latch? INTR = ~(RD | Q); // I think I have Q = ~(STB | INTR); // this right That way you are at least making your latch out of purely combinatorial elements, and aren't depending on the chip being able to detect the rising edges of your strobe and read pulses. I'd be inclined to catch the strobe and read pulses, synchronize them with my internal clock, and have a state machine that implements the above logic. The biggest drawback you'll have then is that the INTR line will go low a bit after the read goes high, but unless your logic is being clocked way slower than the processor you should be OK. -- Tim Wescott Wescott Design Services http://www.wescottdesign.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