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
>The absolute value of an n-bit signed value is at most an n-bit >unsigned value. (An n-bit unsigned value is an n+1 bit signed >value.) Does your absolute value need to be signed? > Ha this is what I was missing! Unsigned numbers still exist! Diego --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147326
Hi, i am confused regarding the ADC/DAC interface implementation on FPGA. I have read a code where after serialising the input data of 16 bits in 16 clock cycles, the interface logic loops (in vain?) for another 16 cyles before serialising the next data. can#t understand why? why the serialisation of the next data is not done immediately. moreover, should the serialisation clock rate be 16 higher than the data stream clock rate? Sorry but i could not find a documentation detailing all the synchronization mechanism. cheers :)Article: 147327
On Apr 22, 8:41=A0pm, alk...@yahoo.co.uk wrote: > Hi, > i am confused regarding the ADC/DAC interface implementation on FPGA. > I have read a code where after serialising the input data of 16 bits > in 16 clock cycles, the interface logic loops (in vain?) for another > 16 cyles =A0before serialising the next data. can#t understand why? Because things work as they are designed...not as they are intended. Do you have a specific question or are you trolling and asking the group to fathom why some unlisted code that is implemented in an FPGA either keeps reading from an ADC or keeps writing to a DAC or perhaps both? > why > the serialisation of the next data is not done immediately. moreover, Thought you just said it tried again, as you say "in vain?"...sounds immediate to me > should the serialisation clock rate be 16 higher than the data stream > clock rate? If the ADC shifts out 16 bits of data, then yes it would need to be at least 16 times as fast as you'd like to sample the analog data. > Sorry but i could not find a documentation detailing all > the synchronization mechanism. > Are you asking the group to find the documentation for you? What you need is the datasheet for whatever ADC or DAC that you're talking about. Try a more informed posting after you've put some though into your question and provide some actual details of what you don't understand and you'll likely get better responses. KJArticle: 147328
On Apr 22, 6:36=A0pm, Patrick Maupin <pmau...@gmail.com> wrote: > On Apr 22, 5:32=A0pm, Andy <jonesa...@comcast.net> wrote: > > > Other than twice the declarations, unintentional latches, explicitly > > coding clock enables, simulation penalties, etc., using separate > > combinatorial and sequential blocks is just fine. > > Unintentional latches don't happen if you use a consistent naming > style with, e.g. 'next_x' and 'x'. > Ha, ha, ha...having a convention naming style prevents latches???!!! Ummmmmm, noooooooo, don't think so, but thanks for the possibly unintended humor. Whether you have a naming convention or not, latches will be created when assignment statements to cover every path are not included in an unclocked process totally independent of how they are named...end of story I suppose your point is that calling things 'next_x' and 'x' then makes it easier to do a *manual* inspection and perhaps catch such a missing assignment but that is a far, far stretch from your actual statement "Unintentional latches don't happen if...". Andy, on the other hand, is on much firmer ground had he said "Unintentional latches don't happen if you only use clocked processes"...he didn't explicitly say that, but I'm fairly certain he would agree. Yes, you can do things to make *manual* inspections better...which is like saying it hurts my head less if I use a rubber hammer to hit my head than a steel one...but it is a far better process improvement to just not hit my head at all with any hammer. KJArticle: 147329
On Apr 22, 8:57=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > I suppose your point is that calling things 'next_x' and 'x' then > makes it easier to do a *manual* inspection and perhaps catch such a > missing assignment but that is a far, far stretch from your actual > statement "Unintentional latches don't happen if...". =A0Andy, on the > other hand, is on much firmer ground had he said "Unintentional > latches don't happen if you only use clocked processes"...he didn't > explicitly say that, but I'm fairly certain he would agree. Yes, I should have been more clear about that. Any decent synthesizer or simulation tool will report latches, but sometimes the reports are hard to interpret. If you use a consistent naming convention like I have described, it is easy to find the latches, and also easy to write a script to find them, as well. And I agree that you won't have latches if all your processes are clocked, but latches are much easier to detect and rectify than some other possible logic problems. Regards, PatArticle: 147330
On Apr 22, 10:12=A0pm, Patrick Maupin <pmau...@gmail.com> wrote: > On Apr 22, 8:57=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > > Yes, I should have been more clear about that. Agreed, you're not very clear when you have statements like this from your previous post... > Unintentional latches don't happen if you use a consistent naming > style with, e.g. 'next_x' and 'x'. followed up with statements like this... > If you use a consistent naming convention like I > have described, it is easy to find the latches, So, first you say that the naming convention by itself will prevent unintentional latches and then follow that up to say that the naming convention helps you to *find* the unintended latches that couldn't be created in the first place...hmmm....yes, I agree, not very clear. Both statements indicating that you may be oblivous to the simple point that using non-clocked processes opens you up to making it easy to create your own problems (i.e. the latches) that are easily avoided in the first place... > And I agree that you won't have latches if all your processes are > clocked, Oop, I guess not because now it seems that you do get the point that clocked processes for the most part avoid the unintended latch...but based on the earlier comments I guess you must not practice it or something for some reason...You admit it avoids a potential design problem, but don't use it because....hmmmm....well, perhaps you have a sponge hammer... Ah well...as long as there are textbooks I guess there will always be those disciples that think that separating combinatorial logic from the register description actually is of some value to somebody, somewhere at some point in time...but inevitably they come up short when trying to demonstrate that value. > easy to find the latches, and also easy to write > a script to find them, as well Then they will trot out the methods they use to minimize the problem that others do not even have. While those disciples are steadfast in their belief, it usually doesn't get across to them that the value they perceive is actually negative, it is costing them...and they are left clinging to the only thing they have left which is always a statement of the form "That's the way I do it, I'm comfortable with it, I feel I'm productive doing it this way" Every now and then, it seems like good sport to challenge those folks to see if they have anything better to offer, but it never seems to be. > but latches are much easier to detect and rectify than some > other possible logic problems. > And much easier to avoid in the first place too...with the correct methodology (hint: that would be the one that avoids using unclocked processes) Just having fun...like I said, every now and then it's good sport to poke fun at the people who make their own problems. Kevin JenningsArticle: 147331
On Apr 22, 11:38=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > > but latches are much easier to detect and rectify than some > > other possible logic problems. > > And much easier to avoid in the first place too...with the correct > methodology (hint: =A0that would be the one that avoids using unclocked > processes) > > Just having fun...like I said, every now and then it's good sport to > poke fun at the people who make their own problems. > But, the reason I was unclear to start with, is that it's been so long since I've had an unintended latch (probably several years) that I really don't think that hard about it at all. So you can think what you want, but the *reason* I code the way I do isn't really that much about latches at all (obviously, if I was *worried* about them, I would code everything in sequential blocks, where they could never happen, but I could have some other hard to find logic problems, which I *have* had in the past). However, unintended latches just don't happen for me with my coding style, so I don't worry about it until somebody like you comes along to tell me about all the problems that I'm causing for myself that I never knew I had! Regards, PatArticle: 147332
On 23 Apr, 02:42, KJ <kkjenni...@sbcglobal.net> wrote: > On Apr 22, 8:41=A0pm, alk...@yahoo.co.uk wrote: > > > Hi, > > i am confused regarding the ADC/DAC interface implementation on FPGA. > > I have read a code where after serialising the input data of 16 bits > > in 16 clock cycles, the interface logic loops (in vain?) for another > > 16 cyles =A0before serialising the next data. can#t understand why? > > Because things work as they are designed...not as they are intended. > > Do you have a specific question or are you trolling and asking the > group to fathom why some unlisted code that is implemented in an FPGA > either keeps reading from an ADC or keeps writing to a DAC or perhaps > both? > > > why > > the serialisation of the next data is not done immediately. moreover, > > Thought you just said it tried again, as you say "in vain?"...sounds > immediate to me > > > should the serialisation clock rate be 16 higher than the data stream > > clock rate? > > If the ADC shifts out 16 bits of data, then yes it would need to be at > least 16 times as fast as you'd like to sample the analog data. > > > Sorry but i could not find a documentation detailing all > > the synchronization mechanism. > > Are you asking the group to find the documentation for you? > > What you need is the datasheet for whatever ADC or DAC that you're > talking about. > > Try a more informed posting after you've put some though into your > question and provide some actual details of what you don't understand > and you'll likely get better responses. > > KJ Wow - grouchy this morning. Did someone piss on your cocoa-pops? ;)Article: 147333
On Apr 23, 5:38=A0am, KJ <kkjenni...@sbcglobal.net> wrote: > Ah well...as long as there are textbooks I guess there will always be > those disciples that think that separating combinatorial logic from > the register description actually is of some value to somebody, > somewhere at some point in time...but inevitably they come up short > when trying to demonstrate that value. http://www.gaisler.com/doc/structdes.pdf I'd recommend casting your eye over this presentation. It details some of the advantages of the "2 process" coding style with a real world example (LEON SPARC-V8 processor). Thanks, ChrisArticle: 147334
Andy wrote: > Other than twice the declarations, unintentional latches, explicitly > coding clock enables, simulation penalties, etc., using separate > combinatorial and sequential blocks is just fine. LoL. Note that there are further difficulties to understand this separated code due to the fact that things which conceptually belong together are spread apart over the file. This is just too messy. > Most designers here use single clocked processes / always blocks. > Those that don't are 'encouraged' to. I'm fully on your side. -- Bernd Paysan "If you want it done right, you have to do it yourself!" http://www.jwdt.com/~paysan/Article: 147335
Chris Higgs <chiggs.99@googlemail.com> writes:
> I'd recommend casting your eye over this presentation. It details some
> of the advantages of the "2 process" coding style with a real world
> example (LEON SPARC-V8 processor).
Actually the rpesentation seems to compare two entirely different
designs done using different approaches. In this comparison, the
Two-Process-style appears to only *one* of the aspects.
--
Marcus
note that "property" can also be used as syntactic sugar to reference
a property, breaking the clean design of verilog; [...]
(seen on http://www.veripool.com/verilog-mode_news.html)
Article: 147336On Fri, 23 Apr 2010 01:03:03 -0700 (PDT), Chris Higgs <chiggs.99@googlemail.com> wrote: >On Apr 23, 5:38 am, KJ <kkjenni...@sbcglobal.net> wrote: > >> Ah well...as long as there are textbooks I guess there will always be >> those disciples that think that separating combinatorial logic from >> the register description actually is of some value to somebody, >> somewhere at some point in time...but inevitably they come up short >> when trying to demonstrate that value. > >http://www.gaisler.com/doc/structdes.pdf > >I'd recommend casting your eye over this presentation. It details some >of the advantages of the "2 process" coding style with a real world >example (LEON SPARC-V8 processor). > Not over the single-process style, which it doesn't even mention. Other aspects of this document are worthwhile, however. - BrianArticle: 147337
On Apr 23, 1:01=A0am, Patrick Maupin <pmau...@gmail.com> wrote: > On Apr 22, 11:38=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > > > > but latches are much easier to detect and rectify than some > > > other possible logic problems. > > > And much easier to avoid in the first place too...with the correct > > methodology (hint: =A0that would be the one that avoids using unclocked > > processes) > > > Just having fun...like I said, every now and then it's good sport to > > poke fun at the people who make their own problems. > > But, the reason I was unclear to start with, is that it's been so long > since I've had an unintended latch (probably several years) that I > really don't think that hard about it at all. The two process people generally do fall back on excuses about being misunderstood. > =A0So you can think what > you want, but the *reason* I code the way I do isn't really that much > about latches at all (obviously, if I was *worried* about them, I > would code everything in sequential blocks, where they could never > happen, Hmmm...so you prefer to take what you admit as unnecessary chances....fair enough, that implies though that you expect some actual benefit from that decision...but are probably unable to come up with an actual example demonstrating that benefit. > but I could have some other hard to find logic problems, which > I *have* had in the past). =A0 Ahhh....one of those examples...now what sort of 'hard to find' logic problem would you like to offer up to to the group to actually demonstrate that two processes are better than one? I'm willing to listen, but I'll warn that you that every time in the past that this debate pops up, the two process people are unable to coherently describe anything other than vague generalities as you've done here...so here is your opportunity to present a clear example describing a 'hard to find' logic problem that is easier to find when coded with two processes. The clocked process folks (i.e. the one process camp) have in the past presented actual examples to back their claims, Googling for 'two process' in the groups should provide some good cases. > However, unintended latches just don't > happen for me with my coding style, so I don't worry about it until > somebody like you comes along to tell me about all the problems that > I'm causing for myself that I never knew I had! Whether you in particular have this problem, I don't know (apparently not). You in particular though are - Doing more work (two process will always be more typing and lines of code then one process), - Producing less maintainable code (two process will always physically separate related things based only on whether the logic signal is a 'register' or not) Kevin JenningsArticle: 147338
On Apr 23, 4:03=A0am, Chris Higgs <chiggs...@googlemail.com> wrote:
> On Apr 23, 5:38=A0am, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > Ah well...as long as there are textbooks I guess there will always be
> > those disciples that think that separating combinatorial logic from
> > the register description actually is of some value to somebody,
> > somewhere at some point in time...but inevitably they come up short
> > when trying to demonstrate that value.
>
> http://www.gaisler.com/doc/structdes.pdf
>
> I'd recommend casting your eye over this presentation. It details some
> of the advantages of the "2 process" coding style with a real world
> example (LEON SPARC-V8 processor).
>
OK, but it doesn't compare it to the 'one process' approach, the
comparison is to a 'traditional method'. The 'traditional method'
though is all about lumping all signals into records (refer to the
'Benefits' area of that document). All of the comparisons are between
'traditional method' which has discrete signals and 'two-process
method' which lumps signals into a record.
There is absolutely nothing comparing 'one process' and 'two
process'. Why the author chose to title his new method the 'two-
process' method is totally unclear...just another example either of
sloppy academic thinking to name your method after something that is
not even relevant to the point of the paper.
The author does mention "No distinction between sequential and comb.
signals" as being a "Problem". Maybe it's a problem for the author,
but it's somewhat irrelevant for anyone skilled in design. The author
presents no reason for why having immediate knowledge of whether a
signal comes out of a flip flop or a gate is relevant...(hint: it's
not). What is relevant is the logic that the signal represents and
whether it is implemented properly or not. Whether 'proper
implementation' means the signal is a flop or not is of very little
concern (one exception being when you're generating gated
clocks...which is a different can of worms).
Even the author's 'State machine' example demonstrates the flaw of
using two processes. Referring to slide #27 partially shown below,
note that (the undeclared) variable v has no default assignment, v
will result in a latch.
begin
comb : process(...., r)
begin
case r.state is
when first =3D>
if cond0 then v.state :=3D second; end if;
when second =3D>
...
This to me demonstrates that the author didn't even take the time to
compile his own code...and not notice the (possibly) unintended latch
that gets generated. Maybe the author is living in an ASIC world
where latches are not a problem, who knows? But in an FPGA, a latch
most certainly is indicative of a design problem more times than not.
You seem to have been caught up by his statement "A synchronous design
can be abstracted into two separate parts; a combinational and a
sequential" and the slide titled "Abstraction of digital logic" and
thought that this was somehow relevant to the point of his
paper...it's not...his point is all about combining signals into
records...totally different discussion.
The only conclusion to draw from this paper is that you shouldn't
believe everything you read...and you shouldn't accept statements that
do not stand up to scrutiny.
Kevin Jennings
Article: 147339fl <rxjwg98@gmail.com> writes: > Hi, > We are developing algorithm on a LYRTech ADC board. There are only 96 > DSP48 on this board. We have a problem of DSP shortage with a FIR > rcosine and low pass FIR design. There is a 105 MHz clock source with > this board. I think a solution is to over clock DSP48 to improve > performance. My question is how to double, triple or quadruple 105MHz > on board clock. Can DCM do the trick? Then, how to get that? Yes a DCM can do that. Just instantiate it (and some BUFGs) and set the parameters up. Read up in the libraries guide and the user guide Alternatively, coregen will guide your through the process and provide you with a VHDL/Verilog file out the backend with an appropriately configured DCM inside it. This is probably worth doing the first time anyway, to see what's involved and what sort of things come out the back end. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 147340
alkosd@yahoo.co.uk pisze: > Hi, > i am confused regarding the ADC/DAC interface implementation on FPGA. > I have read a code where after serialising the input data of 16 bits > in 16 clock cycles, the interface logic loops (in vain?) for another > 16 cyles before serialising the next data. can#t understand why? why > the serialisation of the next data is not done immediately. moreover, > should the serialisation clock rate be 16 higher than the data stream > clock rate? Sorry but i could not find a documentation detailing all > the synchronization mechanism. > > cheers :) Hi, Please specify your ADC DAC type. BR AdamArticle: 147341
On Apr 23, 3:02=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
> OK, but it doesn't compare it to the 'one process' approach, the
> comparison is to a 'traditional method'. =A0The 'traditional method'
> though is all about lumping all signals into records (refer to the
> 'Benefits' area of that document). =A0All of the comparisons are between
> 'traditional method' which has discrete signals and 'two-process
> method' which lumps signals into a record.
I think one of the points (implicitly) made by the paper is an
admission that the two-process method is a mess unless you use
records. I think it's also implied that 'traditional method' people
are more prone to using discrete signals rather than record types.
> The author does mention "No distinction between sequential and comb.
> signals" as being a "Problem". =A0Maybe it's a problem for the author,
> but it's somewhat irrelevant for anyone skilled in design. =A0The author
> presents no reason for why having immediate knowledge of whether a
> signal comes out of a flip flop or a gate is relevant...(hint: =A0it's
> not). =A0What is relevant is the logic that the signal represents and
> whether it is implemented properly or not. =A0Whether 'proper
> implementation' means the signal is a flop or not is of very little
> concern (one exception being when you're generating gated
> clocks...which is a different can of worms).
Sometimes it's necessary to use the combinatorial signal.
>
> Even the author's 'State machine' example demonstrates the flaw of
> using two processes. =A0Referring to slide #27 partially shown below,
> note that (the undeclared) variable v has no default assignment, v
> will result in a latch.
Yes, that's just sloppy.
> You seem to have been caught up by his statement "A synchronous design
> can be abstracted into two separate parts; a combinational and a
> sequential" and the slide titled "Abstraction of digital logic" and
> thought that this was somehow relevant to the point of his
> paper...it's not...his point is all about combining signals into
> records...totally different discussion.
Well combining state into records makes a "two-process" technique neat
enough to be feasible. Personally I use a similar style and I find it
very clear and understandable. As an example:
entity myentity is
generic (
register_output : boolean :=3D true
);
port (
clk : in std_ulogic;
srst : in std_ulogic;
-- Input
data : in some_type_t;
-- Output
result : out another_type_t
);
end;
architecture rtl of myentity is
type state_enum_t is (IDLE, OTHER_STATES);
type state_t is record
state : state_enum_t;
result : another_type_t;
end record;
constant idle_state : state_t :=3D (state =3D> IDLE,
result =3D> invalid_result);
signal r, rin : state_t;
begin
combinatorial: process(r, srst, data)
variable v : state_t;
begin
--DEFAULTS
v :=3D r;
v.result :=3D invalid_result;
-- STATE MACHINE
case v.state is
when IDLE =3D>
null;
when OTHER_STATES =3D>
null;
end case;
-- RESET
if srst =3D '1' then
v :=3D idle_state;
end if;
--OUTPUTS
if register_output then
result <=3D r.result;
else
result <=3D v.result;
end if;
rin <=3D v;
end process;
sequential : process(clk)
begin
if rising_edge(clk) then
r <=3D rin;
end if;
end process;
end;
> The only conclusion to draw from this paper is that you shouldn't
> believe everything you read...and you shouldn't accept statements that
> do not stand up to scrutiny.
You can only use sequential processes and make it impossible to infer
a latch but lose the ability to use a combinatorially derived signal.
Alternatively you can use a two-process technique which allows
intermediate/derived signals to be used but accept the risk that bad
code will introduce latches. We can ague forever about which method is
more 'correct' but it's unlikely to boil down to anything other than
personal preference.
Thanks,
Chris
Article: 147342On Apr 22, 10:04=A0pm, Muzaffer Kal <k...@dspia.com> wrote: > On Thu, 22 Apr 2010 08:08:59 -0700 (PDT), Jan Decaluwe > >Quoting from the article: > >""" > >This example is more subtle and complex than it may seem at first > >sight. As said before, variables dir and run are state variables and > >will therefore require a flip-flop in an implementation. However, they > >are also used =93combinatorially=94: when they change, they may influenc= e > >the counter operation =93in the same clock cycle=94, that is, before the > >flip-flop output changes. This is perfectly fine behavior and no > >problem for synthesis tools, but it tends to confuse a lot of > >designers. > >""" > > I am not sure who is really confused here. You are: both about Verilog (suprizing) and about RTL synthesis (anticipated). > What is suggested in the > above paragraph is not really feasible; assuming by 'dir' one refers > to the output of a flop. > > The problem with the last verilog block shown is the dir and run are > not flops anymore but combinational signals decoded from goleft and > goright so the last direction will not be remembered. If last > direction needs to be remembered, one needs to decode the > 'instruction', use =A0the decoded value and remember the decoded value > as above. So this is now already the third post that I devote to explaining to two seasoned Verilog designers how a very simple example in their favourite language with the ultra-short learning curve actually works. I'm beginning to think that Verilog designers don't know how to use variables :-) 'dir' and 'run' keep their value over always block invocations, OK? Depending on the conditions, they may or may not get a new value. Basic Verilog stuff. Then the implementation. Clearly there is both a sequential and a combinatorial path from these variables. If you think this is not feasible, don't argue with me, but just synthesize it and simulate the result to verify. FInally, RTL synthesis. No, 'dir' is not a flop and no, it isn't combo logic either. It gives rise to both. Technically, the same variable 'dir' creates multiple nodes in a multi-level logic network that represents the code. Voil=E0. JanArticle: 147343
Coding clock enables in a combinatorial process requires an additional assignment for the clock-disable case (otherwise you get a latch, regardless of your naming convention). Only one assignment is required (the enabled assignment) in a clocked process, and it is the assignment you had to make anyway. KJ has already well stated the problems with latches (requiring additional assignments) in combinatorial processes/blocks, regardless of the naming convention employed. Any decent simulator (maybe not a half-decent one) will merge processes or always blocks that share the same sensitivity list. Since they are usually identical for all synchronous processes clocked by the same clock, they get merged, thus improving performance by avoiding duplicative process-related overhead. Since combinatorial processes rarely share the same sensitivity list, they don't get merged, and performance suffers. AndyArticle: 147344
<alkosd@yahoo.co.uk> wrote in message news:3bf71478-a08c-4165-9af5-98edd3548e89@8g2000yqz.googlegroups.com... > Hi, > i am confused regarding the ADC/DAC interface implementation on FPGA. > I have read a code where after serialising the input data of 16 bits > in 16 clock cycles, the interface logic loops (in vain?) for another > 16 cyles before serialising the next data. can#t understand why? As suggested by others your question is very vague, however, some SPI ADC have the option to stream out the LSB first. In order to do this you first need to stream out the MSB_first word and then you can read the LSB_first word (this makes perfect sense for a successive approximation ADC). Thus in the LSB case you need 2 sets of n-bit clock cycles. Find the datasheets and (hopefully) all should become clear, Hans www.ht-lab.com > why > the serialisation of the next data is not done immediately. moreover, > should the serialisation clock rate be 16 higher than the data stream > clock rate? Sorry but i could not find a documentation detailing all > the synchronization mechanism. > > cheers :)Article: 147345
On Apr 23, 10:34=A0am, Andy <jonesa...@comcast.net> wrote: > Coding clock enables in a combinatorial process requires an additional > assignment for the clock-disable case (otherwise you get a latch, > regardless of your naming convention). Only one assignment is required > (the enabled assignment) in a clocked process, and it is the > assignment you had to make anyway. Oh, I see the point you're trying to make. Two points I tried (and obviously failed) to make are that (1) I don't mind extra typing, because it's really all about readability (obviously, from the discussion, my opinion of what is readable may differ from others); and (2) With the canonical two process technique, the sequential process becomes boilerplate (even to the point of being able to be generated by a script or editor macro, in most cases) that just assigns a bunch of 'x <=3D next_x' statements. The top of the combinatorial process becomes boilerplate as well, with corresponding 'next_x =3D x' statements (for some variables, it could be other things, e.g. 'next_x =3D 0'. But you can just glance at those and not think about it. So, when reading, you aren't really looking at that, or the register declarations. Once you accept that the sequential block, and the top of the combinatorial block, are both boilerplate that you don't even need to look at, then it's no more work than anything else. (In fact, if you can type faster than 20 wpm and/or know how to write scripts or editor macros, it's less work overall.) > KJ has already well stated the problems with latches (requiring > additional assignments) in combinatorial processes/blocks, regardless > of the naming convention employed. I understand the issue with latches. I just never see them. The coding style makes it easy to check and avoid them. It can even be completely automatic if you have a script write your boilerplate. > Any decent simulator (maybe not a half-decent one) will merge > processes or always blocks that share the same sensitivity list. Since > they are usually identical for all synchronous processes clocked by > the same clock, they get merged, thus improving performance by > avoiding duplicative process-related overhead. Since combinatorial > processes rarely share the same sensitivity list, they don't get > merged, and performance suffers. I'm pretty sure that verilator is smart enough to figure all this out. That's the simulator I use if I care about execution time. Regards, PatArticle: 147346
On Apr 23, 8:12=A0am, KJ <kkjenni...@sbcglobal.net> wrote: > The two process people generally do fall back on excuses about being > misunderstood. Well, I'm not going to generalize about "one process people" but at least some of them are supercilious bastards who think that anybody who doesn't do things their way is an idiot. BTW, this is the last post I'm going to reply to you on, so feel free to have fun with more piling on. > Hmmm...so you prefer to take what you admit as unnecessary > chances....fair enough, that implies though that you expect some > actual benefit from that decision...but are probably unable to come up > with an actual example demonstrating that benefit. Well, I haven't used the single process style in many years, so no, I can't point you directly to the issues I had that led me to switch. But I have helped others to switch over they years, and they have all been grateful. In any case, I posted elsewhere in this thread a pointer to Cliff Cumming's paper on blocking vs non-blocking assignments. I assume you've been studiously avoiding that for plausible deniability, so here it is: http://www.sunburst-design.com/paper= s/CummingsSNUG2000SJ_NBA.pdf If you read this paper carefully, you will come to an understanding that, while it is often possible to follow it using a single process method, in many cases, in order to follow it, you will have to assign related variables from *different* sequential processes (one blocking sequential process, one non-blocking sequential process). With the sequential/combinatorial process method, using the boilerplate for sequential processes is actually very easy and requires little thinking, and allows you to do all the real work of coding on related variables within the same combinatorial process, with a sequential boilerplate process. You can concentrate all your hard thinking on the problem at hand, in the non-boilerplate code in the combinatorial process. > > but I could have some other hard to find logic problems, which > > I *have* had in the past). =A0 > > Ahhh....one of those examples...now what sort of 'hard to find' logic > problem would you like to offer up to to the group to actually > demonstrate that two processes are better than one? =A0I'm willing to > listen, but I'll warn that you that every time in the past that this > debate pops up, the two process people are unable to coherently > describe anything other than vague generalities as you've done > here...so here is your opportunity to present a clear example > describing a 'hard to find' logic problem that is easier to find when > coded with two processes. =A0The clocked process folks (i.e. the one > process camp) have in the past presented actual examples to back their > claims, Googling for 'two process' in the groups should provide some > good cases. That's because you're *not* really willing to listen. If you were, you would have heard, from me, anyway, loud and clear, that it's not really about the *language constructs*, it's about how much people can hold in their heads at a single time. The two process method reduces the need for that, so even if I presented an example where it helped me in my thinking, you would just superciliously explain how any idiot should have seen the error in the one process method, so it doesn't prove anything. Since you're the smartest asshole in the world, the two process method couldn't possibly offer any benefits you would be interested in, so just forget about it. > - Producing less maintainable code (two process will always physically > separate related things based only on whether the logic signal is a > 'register' or not) See, this is another place where you haven't listened. What don't you understand about 'boilerplate'? It's a tiny bit of overhead, not really part of what you need to worry about in maintenance. It is easily checked and even automated. Regards, PatArticle: 147347
On Fri, 23 Apr 2010 08:32:48 -0700 (PDT), Jan Decaluwe <jan@jandecaluwe.com> wrote: >So this is now already the third post that I devote to explaining >to two seasoned Verilog designers how a very simple example in >their favourite language with the ultra-short learning curve >actually works. I'm beginning to think that Verilog designers >don't know how to use variables :-) > Actually it was mostly a matter of not paying close attention to something one "knows" would not work. Of course in a clocked process if a register is not assigned in a path it remembers its value so a register is inferred and if it's a blocking assignment, its value is available in the same clock cycle. When one finally puts these together, your example is "obvious". And you're right; personally I don't use variables in this fashion. I would write the same logic as follows: if (turnleft) was_turnleft <= 1; if (turnleft || was_turnleft) do_left turn; which I think how the synthesizer would generate the logic for your example. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 147348
On Apr 21, 1:08=A0pm, Jon Beniston <j...@beniston.com> wrote: > It's running ok for me on Windows 7 64-bit. > > What particular part of the software are you having problems with? > > Jon Well it installs alright, but Altium Designer 6 can't find it - whereas it did on my XP box. One problem is that Windows 7 likes to put 32 bit legacy programs under Program FIles(x86), but Quartus won't install there because it can't handle spaces or special characters in it's filenames.Article: 147349
On Apr 21, 6:42=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Wastrel <stephensdigi...@gmail.com> wrote: > > My XP box died the other day and was replaced by a 64 bit Windows7 > > machine. Now my $%^&Quartus II software won't run, and Altera says > > Win7 ain't supported. Anybody know of a workaround? I'm developing on > > the Altera Cyclone III FPGA on the Altium Designer NanoBoard 3000. > > Win7 has an option to tell the program that it is running on > a previous version of windows, as far as such checks are concerned. > > As far as the design software, that is likely to work. > > As you might need a device driver to talk to USB to download > the bitstream, that might be system dependent, such that it > won't work. > > -- glen The bitstream gets downloaded by Altium Designer via JTAG and that part still works. Can you elaborate on the previous version of windows option. As I mentioned earlier, running Quartus under Program Files(x86) won't work becuase Quartus won't install under that directory. Thanks, Bob
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