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
"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message
news:v014f15eflkh1qr14fkharpa1rsdl5sp40@4ax.com...
> On Thu, 4 Aug 2005 15:47:16 +1000, "Paul Solomon"
> <psolomon@tpg.com.au> wrote:
>
>>Hi,
>>
>>I was wanting to know if there was a way to auto-generate a mif or hexout
>>file in quartus (or in general verilog) based on the set parameters in a
>>verilog file?
>>
>>The application is for a NCO function that used a memory lookup (for sin
>>table) approach rather that cordic. The sin table can be auto generated by
>>a
>>perl script that I can write in which I can manually set the memory depth
>>and amplitude resolution (which are parameters of the NCO) however I would
>>like the module to allow the end user to set an arbitrary bit width and
>>phase angle width and at synthesis time have a script or some other clever
>>code generate the required memory file for me.
>>
>>If anyone has any ideas how to achieve this kind of trickery I would
>>apreciate the advise.
>
> Here's just one possible idea - not tested, but I think it will work.
>
> Here's your parameterisable module:
>
> module Wotsit(a,d);
> parameter nA = 8; // number of address bits
> parameter nD = 10; // number of data bits
> input [nA-1:0] a;
> output [nD-1:0] d;
>
> always @a
> d = <some function of a, will synthesise to ROM>;
>
> `ifndef SYNTHESIS
> // this line is executed for simulation only
> initial $display("Wotsit_instance %m: nA=%0d, nD=%0d", nA, nD);
> `endif
>
> endmodule
>
> Now, when you simulate, you get a line in the transcript that
> has all the relevant information in it. Get a Perl or Tcl script
> to process the transcript to extract those lines and munge them
> to construct the appropriate memory file, with an appropriate
> file name.
>
> There's an urgent need for a little Perl or Tcl utility that
> will convert among all the various memory-image formats that
> we EDA folk need - Verilog $readmemb, Xilinx and Altera
> memory formats, Intel hex and so on. Perhaps someone has
> already done it?
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services
>
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
> Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573 Web: http://www.doulos.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
Hi Johnathan,
Thanks for this, this is good. I have already got a perl and a tcl script to
generate the memory files, and I think I could adopt them to use this
method.
There is one other missing peice though..
in my top level design I want to create 2 instances of this module with
different parameters, I will then need to create 2 different memory files
with different names (one for each instance that has different parameters).
In the definition of this nco module I need a clever way to reference the
different files. I know I could make a string parameter filename =
"sin_lut_A_B.mif" etc however, I would much rather a way I can auto generate
this string within the verilog code so that it automaticcaly looks for the
correct file based on the parameters.
this filename needs to be passed to another module (the rom) as a defparam.
If you have any ideas here I would love to hear them, and thanks for your
help so far!
Regards,
Paul Solomon
Article: 87951
Martin Thompson wrote:
> [...]
> > The main point of tigher coupling is so that anything that affects one
> > leg will also affect the other leg - allowing it to be cancelled out by
> > the differential receiver. I don't know exactly what his definite of
> > loosely coupled is, but if it is "loose" enough that an aggressor
> > signal could affect one leg of the pair much more than the other, it
> > throws out the main benefit of using differential pairs in the first
> > place.
> >
>
> But most of the aggressors are likely to be other PCB traces, and they
> are *not* going to couple symmetrically onto the pair. My
> understanding is that you just can't couple PCB traces that well.
>
> The main benefit of using differential pairs for signals is off-board
> using twisted pair cabling. So long as your PCB traces match in delay
> (not length), you've got what you can out of them.
Howdy Martin,
I think that tight vs. loose coupling discussions come up every year
or so on the SI-list. Each has its supporters, for different reasons
(including debating how well the _p and _n legs couple when routed
tightly). But I don't believe there is any real debate that aggressors
can and will affect nearby signals - in fact, we've had it happen on a
few different prototypes in our lab (admittedly, we run pretty dense
boards). It's all a function of distance between the traces.
BTW, I don't think I ever answered JF's original query - we use
RocketIO's exactly the same way he has it set-up, even down to using
Finisar (internally AC-coupled) optics. It works like a hose.
Regards,
Marc
Article: 87952On Thu, 4 Aug 2005 22:33:58 +1000, "Paul Solomon" <psolomon@tpg.com.au> wrote: >There is one other missing peice though.. > >in my top level design I want to create 2 instances of this module with >different parameters, I will then need to create 2 different memory files >with different names (one for each instance that has different parameters). >In the definition of this nco module I need a clever way to reference the >different files. I know I could make a string parameter filename = >"sin_lut_A_B.mif" etc however, I would much rather a way I can auto generate >this string within the verilog code so that it automaticcaly looks for the >correct file based on the parameters. > >this filename needs to be passed to another module (the rom) as a defparam. I think you'll find that my suggestion deals with this. The idea is that the module contains a $display statement that writes out the value of its parameters (nA, nD in my example) and also its hierarchical instance name using the %m specifier in $display. This $display statement won't get executed until the whole thing is elaborated in the simulator, so somewhere early in the transcript you should see lines that look like this... Wotsit_instance top.widget.coarse_nco.LUT: nA=7, nD=4 Wotsit_instance top.widget.fine_nco.LUT: nA=12, nD=16 Because these lines start with a really unusual string (Wotsit_instance) and have a fixed format, you could easily grep through the transcript looking for them and pulling out the information from those lines. Because the lines also contain the full hierarchical path names to the LUT instances, you can patch-up the memory files to deal with those specific instances. Apologies if I've missed the point, but I think it will work. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 87953
On 3 Aug 2005 05:59:31 -0700, "Brandon" <killerhertz@gmail.com> wrote: >I'm experiencing an error using XST during synthesis involving a type >conversion on a port instance: >http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=18188 > >Is this legal syntax in the vhdl standard? Yes. There was a change from VHDL-87 to VHDL-93 that fixed a silly inconsistency: VHDL-87 didn't accept array type conversions on a port map, so for example if you have a std_logic_vector signal S and you want to connect it to an "unsigned" input port P: ... port map (... P => unsigned(S) ...) is legal in VHDL-93 but was forbidden in '87. >I was told by a Xilinx applications engineer that they don't have a fix >and I have to do the workaround. What a pain... Do the other synthesis >tools support this syntax? Mostly, yes. The workaround is hardly a big deal, though. Just tedious. It may be cleaner to do the workaround by building a wrapper entity, so that you can hide the type conversion and its associated extra signal in the wrapper rather than exposing it in the upper-level entity. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 87954
<jjlindula@hotmail.com> wrote in message news:1123088364.723402.137130@g47g2000cwa.googlegroups.com... > What? > ..... Go ride a bike. Turn a corner. Now start thinking about/analysing what you are doing. Turn a corner. DNAArticle: 87955
"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message
news:bo44f19klcleqnmc4jnj1r9r89mtqj784o@4ax.com...
> On Thu, 4 Aug 2005 22:33:58 +1000, "Paul Solomon"
> <psolomon@tpg.com.au> wrote:
>
>>There is one other missing peice though..
>>
>>in my top level design I want to create 2 instances of this module with
>>different parameters, I will then need to create 2 different memory files
>>with different names (one for each instance that has different
>>parameters).
>>In the definition of this nco module I need a clever way to reference the
>>different files. I know I could make a string parameter filename =
>>"sin_lut_A_B.mif" etc however, I would much rather a way I can auto
>>generate
>>this string within the verilog code so that it automaticcaly looks for the
>>correct file based on the parameters.
>>
>>this filename needs to be passed to another module (the rom) as a
>>defparam.
>
> I think you'll find that my suggestion deals with this. The idea
> is that the module contains a $display statement that writes out
> the value of its parameters (nA, nD in my example) and also its
> hierarchical instance name using the %m specifier in $display.
> This $display statement won't get executed until the whole
> thing is elaborated in the simulator, so somewhere early in the
> transcript you should see lines that look like this...
>
> Wotsit_instance top.widget.coarse_nco.LUT: nA=7, nD=4
> Wotsit_instance top.widget.fine_nco.LUT: nA=12, nD=16
>
> Because these lines start with a really unusual string
> (Wotsit_instance) and have a fixed format, you could easily
> grep through the transcript looking for them and
> pulling out the information from those lines. Because the
> lines also contain the full hierarchical path names to the
> LUT instances, you can patch-up the memory files to deal
> with those specific instances.
>
> Apologies if I've missed the point, but I think it will work.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services
>
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
> Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573 Web: http://www.doulos.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
I am not sure that we are on the same page here.. I am trying to have this
work for synthesis, not simulation, the mif file will be a rom image. I kind
of have it working now the way I want with this code...
module nco(clk, clk_en, reset, phi, sin, cos);
parameter ACC = 18;
parameter PHA = 17;
parameter PHA2 = "17";
parameter AMP = 12;
parameter AMP2 = "12";
--- skipped various lines to get to interesting bit----
altsyncram sin_lut( .address_a(phase),
.clock0(clk),
.q_a(sin_out));
defparam sin_lut.OPERATION_MODE = "ROM";
defparam sin_lut.WIDTH_A = AMP-1;
defparam sin_lut.WIDTHAD_A = PHA-3;
defparam sin_lut.INIT_FILE = {"sin_lut_",PHA2,"_",AMP2,".mif"};
I would ideally like to defing this last line here in terms of PHA and AMP
without having to use the additional dodgy PHA2 and AMP2, this would also
prevent the wrong file from being used.
Regards,
Paul Solomon
Article: 87956Thanks a million for the reference link, I'll check it out.Article: 87957
On Thu, 4 Aug 2005 23:48:34 +1000, "Paul Solomon"
<psolomon@tpg.com.au> wrote:
>I am not sure that we are on the same page here..
Sorry, I had quite badly misunderstood you.
> I am trying to have this
>work for synthesis, not simulation, the mif file will be a rom image. I kind
>of have it working now the way I want with this code...
>
>module nco(clk, clk_en, reset, phi, sin, cos);
> parameter ACC = 18;
> parameter PHA = 17;
> parameter PHA2 = "17";
> parameter AMP = 12;
> parameter AMP2 = "12";
>
>--- skipped various lines to get to interesting bit----
>
>altsyncram sin_lut( .address_a(phase),
> .clock0(clk),
> .q_a(sin_out));
>
> defparam sin_lut.OPERATION_MODE = "ROM";
> defparam sin_lut.WIDTH_A = AMP-1;
> defparam sin_lut.WIDTHAD_A = PHA-3;
> defparam sin_lut.INIT_FILE = {"sin_lut_",PHA2,"_",AMP2,".mif"};
OK. What I was trying to get at was this: Suppose the upper-level
module instantiates
nco #( 22, 19, "19", 10, "10") this_nco (....);
// ACC, PHA, PHA2, AMP, AMP2
You need to prepare, in advance, the file "sin_lut_19_10.mif".
My $display trick was intended to make it possible to automate
that step, based on the design itself.
>I would ideally like to defing this last line here in terms of PHA and AMP
>without having to use the additional dodgy PHA2 and AMP2, this would also
>prevent the wrong file from being used.
Understood.
Verilog-2001 $sformat() will do the job, but it's fairly certain that
the synth tool won't accept that.
Here's another idea: Use the numbers to build an ASCII code...
again this depends on a Verilog-2001 feature, sized parameters.
parameter PHA = 17;
parameter AMP = ...
// Don't let users mess with the following:
//
parameter [7:0] PHA2 = "A" + PHA;
// 0 -> "A", 1 -> "B", .... 25 -> "Z"
Now PHA2 is an automatically-generated 1-character string and
your file name will be something like sin_lut_Q_M.mif -
a Perl script can presumably easily infer the numbers from that.
I don't know whether Quartus will accept sized parameters, but
most tools are OK with it.
Sorry to be so stupid about your original problem.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 87958
On Thu, 4 Aug 2005 07:59:08 -0400, "Clay S. Turner"
<Physics@Bellsouth.net> wrote:
>
>"Jim Thompson" <thegreatone@example.com> wrote in message
>news:tqv1f19en0pj7rclndiq6r8uvn0mbg3uho@4ax.com...
>> >
>> The EARLY Pentiums were architected by a single person. Need I say
>> more ?:-)
>>
>> ...Jim Thompson
>
>Is this the one that couldn't divide very well. I.e., had the floating point
>bug?
>
>Clay
>
>
Yes, But certainly not the one who made P4's slower than P3's, for
numerical operations.
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice:(480)460-2350 | |
| E-mail Address at Website Fax:(480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
Article: 87959
On Thu, 04 Aug 2005 13:25:29 GMT, "Genome" <ilike_spam@yahoo.co.uk>
wrote:
>
><jjlindula@hotmail.com> wrote in message
>news:1123088364.723402.137130@g47g2000cwa.googlegroups.com...
>> What?
>>
>
>
>.....
>
>Go ride a bike. Turn a corner.
>
>Now start thinking about/analysing what you are doing. Turn a corner.
>
>DNA
>
ROTFLMAO ;-)
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice:(480)460-2350 | |
| E-mail Address at Website Fax:(480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
Article: 87960Ankit, I am the wrong person to ask, for I, personally, find the whole subject bogus. But that's my problem... Peter AlfkeArticle: 87961
Peter, Have you designed your own DDS or reused Xilinx free core? I am not familiar with this core yet, so I am not sure of what it's capable of. I assume it does not allow you to produce 1Hz to 640MHz, that's why your design is unique. Or if it does, then I guess it's unique in a way that it fits in a small box and has low clock jitter.Article: 87962
no idea, sorry. though, i dont remember changing switches from the default setupArticle: 87963
>>> synchronizing the reset to your local cock(s) > > nooooo, you really don't want to do that at all. Jolly painful. Jonathan, I hope you're not being rude ;-) > See the recent thread "Bulletproofing CPLD Design" on comp.lang.vhdl > for further suggestions from me and others on this issue. To recap, Jonathan suggests..... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - Datapaths, configuration registers etc have simple asynch reset. - Sequence-control state machines have asynch reset, but also have synchronous reset signal that holds them in their idle state. - Arrange one small dedicated piece of logic that is reset by asynch reset, and holds the synch reset signal active for two clocks after asynch reset has been released. Now, your sequence controllers will remain in their idle state for two clocks after the end of asynch reset. While they are in the idle state, no other activity will run in the other parts of the design. Consequently, it doesn't matter what happens to the other flip-flops immediately after the end of asynch reset. But the synchronous reset is applied only to a small part of the design (the sequence control FSMs) so it consumes very little extra logic. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which is similar to the approach I take, except often the synchronous reset can also be triggered by an SBC/CPU or whatever to get the FPGA to a known state. The question still remains... "If you drive flip-flop asynchronous reset inputs from a synchronous source, are the tools intelligent enough to include these paths and the flip-flop reset mechanism in the timing analysis"? If so then the extra synchronous reset logic could also be dispensed with. Anybody from Altera/Xilinx want to comment? Nial.Article: 87964
Andrew, Thanks for the great tips, I did see the same minimum frequency for the DCM when not using the DLL feature, and read some of the XAPP462. I think this should get me rolling. cyArticle: 87965
"DDS" is really just a simple (but long) accumulator, 27 bits long in my case, and there would be no problem making it 10 bits longer, getting down to one millihertz. I did not use any core for that, it's trivial. All the user- and display interface is done with Ken Chapman's PicoBlaze (thanks, Ken!). The trickery is in reducing jitter from the inherent 6 ns (one internal clock period of 160 MHz) to the more acceptable <100 ps. And I am still playing around with better or more elegant solutions. 50 ps cycle-to-cycle jitter (and no wander) is the goal. Fancy and expensive instruments have about that performance. It would be nice to beat them at less than 1/10 the cost. Another realistic goal is to get the max frequency to 2 GHz, and perhaps higher (using MGTs). 0.5 Hz to 5 GHz would be ten decades, driven out of one MGT ! Peter AlfkeArticle: 87966
Hi Cyd, I suggest you read the clock jitter specs for your ADC carefully. Clock jitter raises the noise floor, since the ADC converts timing noise into amplitude noise. Peter AlfkeArticle: 87967
Dear Cyd, There are two issues you would have to address. (*) You are able to generate 80 MHz out of 20, if you use CLKFX output ONLY, as the minimum frequency for this case is 1 MHz. I did this. It's working. (**) Using CLKFX implies that you would have some jitter induced by frequency synthesizer as per its tapped delay line's nature. Vladislav "cyd" <cyd@spectrum.montana.edu> wrote in message news:1123106212.167172.101760@o13g2000cwo.googlegroups.com... >I am looking for some help in regards to a 20 MHz modulation clock that > needs to set the timing in the Virtex_II_Pro. I was investigating > running the modulation clock into a DCM; However, the minimum input > frecquency for CLKIN is 24MHz. The 20 MHz modulation clock needs to > establish the timing in the FPGA for synchronizing the 80MHz ADC and > for digital mixing of the modulation frequency. If I can not use a DCM, > how do I create the synchronous timing for my subsystems 80MHz and > digital mixing? >Article: 87968
Good question (*) Profound architecturing before coding & methodological approach. (**) Design Automation, scripting (even you have a PC, and not some heavy duty washer like ultrasparc) (***) Choosing a good FPGA design engineer (I'd place this one first on the list) Vladislav "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:11f2ff9m3g0qj10@corp.supernews.com... > >you can not use one project for different (size/family) FPGAs > > It seems like one should be able to set up one project > with multiple parts and be able to assign different packages. > > What do the big boys do? I've seen plenty of boards with > more than one Xilinx on them. > > Brad > > >Article: 87969
Sumesh, You have asked a very good question., quite a few people really ask it. It depends on several factors, such as the speed of the design, percentage of used resources and more... I have met 30% / 70% logic / routing delay distribution, as well as 70% / 30%. Do not account this into your simulation environment, because the best simulation you could find is the board with FPGA Unless you are designing ASIC....... V "vssumesh" <vssumesh_asic@yahoo.com> wrote in message news:1123050930.861121.280660@z14g2000cwz.googlegroups.com... > thanks Vladislav.. it worked perfectly... > can i substitute this process for the real fpga.... > what is the effect of routing delays compared to the component > delays.... > how can i account for that in the simulation environment... > > Sumesh >Article: 87970
Hello group, I've got 3 Spartans and three platform PROMs in my JTAG daisy chain. Now I can load the first Xilinx fine, but only if I load it first. If I load the second Xilinx and then try to load the first, the Done pin won't go high. Any suggestions? Brad SmallridgeArticle: 87971
Hmm. I have to admit that I didn't think of this. So you can register your reset at the IO pin and then have that synced output drive the internal global reset? Is that right? >> Actually this is a false compromise. There is a perfectly safe way of >> synchronizing the reset to your local cock(s) so that there is no >> chance of metastability regardless of the reset release time. This way >> you can continue to use async resets.Article: 87972
Evolutionary Algorithms do have their place.
During my Masters program a friend and I wrote a piece of software that
would take a logic circuit and generate a set of test vectors that
would give you the best fault coverage.
The program did this using a "Genetic Algorithm" approach.
First a random set of test vectors were created. Then the set of
vectors were repopulated based on a fitness function. (Basically if the
test vector had a high % of fault coverage it was more likely to be
selected back in the set of vectors) After that there is a
mutation/cross over phase which adds more variants to the population.
These 3 steps are repeated until a certain % of fault coverage is
completed by a set of the vectors.
The upside to this approach is it can be a lot faster than an
exhaustive approach, especially if the circuit is large. The downside
is every time you run the program you get a different answer. The
whole value of this and other evolutionary methods are how good is the
fitness function.
I'm not sure how you would use evolutionary methods in an FPGA.
Unless you wanted a hardware version of what my program does... create
a set of test vectors to test your ASIC every time it boots up. But I
probably need to read Adrian's paper aswell.
It is an interesting topic even if it might only academic merit at the
present.
Here are the references for the paper I wrote on this program.
1) Rudnick, E. , "Application of Simple Genetic Algorithms to
Sequential Circuit Test
Generation", Center for Reliable and High-Performance Computing,
University of
Illinois, Urbana, Il 61801
2) Rudnick, E., "Sequential Circuit Test Generation in a Genetic
Algorithm Framework",
Center for Reliable and High-Performance Computing, University of
Illinois, Urbana, Il 61801
3) Corno, F., "A Parallel Genetic Algorithm for Automatic Generation
of Test Sequences
for Digital Circuits", Dip. Automatica e Informatica -
Politecnico di Torino, Torino
Italy
4) Prinetto, P., "An Automatic Test Pattern Generator for Large
Sequential Circuits
based on Genetic Algorithms", Dip. Automatica e Informatica -
Politecnico di Torino,
Torino Italy
Eric Holland
Article: 87973I should have been more specific: I can imagine creative and useful ways to write software, and test vectors, i.e. zeros and ones in an evolutionary way. I just have a hard time with evolutionary hardware, where Adrian created a frequency discriminator that worked, but defied any method of circuit analysis (and repeatability, and stability over temperature). Peter Alfke (just my personal opnion).Article: 87974
Brad Smallridge wrote:
> Wow, that's an interesting use of procedures to automatically
> restructure a program.
I like to play with templates.
For production code, I just pick one and use it.
> I brought the question of async vs. sync reset to the group awhile ago,
> and someone told me (they should harp in here to get credit), that with
> an async reset you may have metastable issues when your reset goes
> inactive, which sort of defeats the purpose of having a reset.
Unless the inactive edge is synchronized.
> So this
> sold me on sync resets, end of story.
That will work fine.
>
> When does a CPU know when to reset the FPGA?
In our system, the cpu runs the show.
The FPGA is just one of many chips
that is initialized during boot up.
-- Mike Treseler
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