Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On 9/13/2015 1:35 AM, glen herrmannsfeldt wrote:
> rickman <gnuarm@gmail.com> wrote:
> (snip, I wrote)
>>>>>>> I write structural verilog, or more recently structural VHDL.
>
>>>>>> I'm not sure what you mean by that. Everyone writes structural HDL.
>>>>>> But they also write the code in the blocks that gets connected by the
>>>>>> structural HDL. Don't you? That is the hard part.
>
> (snip, I wrote)
>
>>> Well, in verilog you can write combinatorial logic with either
>>> continuous assignment not in an always block, or a behavioral
>>> assignment (that is what the book nearby seems to call it) in
>>> an always block. Two different ways to say the same thing.
>
>>> The only way I make registers and latches in verilog is with
>>> an always block. It might be that it can be done in VHDL without
>>> a process block, but so far I use one, such that it looks similar
>>> to the matching verilog.
>
>> Yes, if you want, you can describe a FF in a continuous assignment in
>> VHDL, but it is very unconventional and not very malleable.
>
>> I'm not sure why you are drawing some of the distinctions you do. I
>> have never seen anyone consider continuous assignments to be
>> "structural" HDL. Rather complex logic can be defined that way although
>> I think most logic ends up in processes or the equivalent.
>
> OK, it seems that the book I have calls the continuous assignment
> form data-flow model.
"Data-flow" is a completely unrelated concept from my experience. I
have no idea what they mean by that. Verilog jargon perhaps? I am not
conversant in Verilog as much as VHDL where they are called concurrent
assignments.
There is no difference between a concurrent assignment and a process
with just one assignment and a sensitivity list with all input signals.
In general, a process can have many assignments including variable vs.
signals and the sensitivity list can include just a subset such as (clk,
rst) for a clocked process.
I looked up "Verilog data flow" and found no real definition of it and
found it used in different ways on each page. One page refers to
"structural data flow modelling" and "Behavioral data flow modelling".
I think the term "data flow" should be ignored in this context and just
"structural" and "behavioral" should be used.
In my book (the one in my head) "behavioral" includes any inference of
logic while "structural" is instantiated.
To muddy the waters a bit, I see the term "RTL" (register transfer
level) which is behavioral, but implies the level of abstraction does
not rise above describing specific registers and logic.
> (snip)
>>>> Sure, the two are very different. Behavioral code requires thinking and
>>>> analysis. Structural code is just a matter of wiring together blocks.
>
>>> I consider continuous assignment part of structural, though it might
>>> have another name, and some logic goes in there.
>
>> I only consider instantiations to be structural. Continuous assignments
>> have several logical constructs which will infer logic and are often
>> used that way. It is actually seldom that I use continuous assignments
>> for structure since the connections are made in the component
>> instantiations. Why would I want to connect two wires with an
>> assignment unless there was something very odd going on like one wire
>> into a module connected to two wires going out? I don't know I have
>> ever done that.
>
> A lot of my VHDL assignments are putting together or taking apart
> vectors. It seems that VHDL feature is too new. So I have:
>
> y29 <= (a, b, c, d);
> -- instantiate entity using y29.
I am pretty sure you can use (a, b, c, d) in the component port map.
But there are some specific details on this and I haven't done much with
any HDL for a while so I've forgotten the finer points. (a, b, c, d) is
called and aggregate in VHDL.
>>> Some can be written about the same either way. When I have a
>>> choice between verilog continuous assignment and behavioral assignment,
>>> I choose the former, others might choose the latter.
>
>> Not sure why that matters. If it generates logic, it is not structural.
>> I think we have a *big* difference in definitions. Behavioral does
>> not imply any type of assignment to me. It is a method of designing
>> logic by describing how the logic works rather than describing how it is
>> constructed. Both concurrent and sequential coding is used for
>> behavioral design.
>
>> Purely structural design would use instantiation only without inference
>> by any statement type other than within the primitive units.
>
> I suppose, but structural plus continuous assignment takes too
> long to write.
I don't follow. I thought you said that was what you do!
>> Of course my designs are never purely behavioral without use of module
>> instantiation. It is easier to test a design in pieces, then glue the
>> pieces together and test again. I think our disagreement is how far
>> down the modules are divided. My typical module size is a couple dozen
>> to a hundred or so lines. Although the really large ones are the top
>> level gluing it all together with structural code. One of my smaller
>> top level modules is over 600 lines of glue. Not hard to get right
>> using the tools that let me copy and paste with regular expression
>> conversions. Errors creep in when changes are made.
>
> I suppose, but I do know people who write mostly behavioral,
> with one big process block in each entity.
Yeah, I find one process per entity to be a bit awkward. I use multiple
processes to organize my thoughts. So each process will have a
functional purpose. Some small like a resynchronizer with just two FFs,
or some large with logic that is more than one register, but with
complex interaction which are awkward to break apart. Personal
preference. I just don't like very large processes so that it becomes
hard to see what is going on.
>>> I usually put registers into their own module, even if that is the
>>> only thing in the module.
>
>>> One that I am working on now is exactly taking a design in SSI and
>>> MSI and writing it in VHDL. The SSI (gates) go into assignment
>>> statements with the appropriate logical operations. MSI (anything
>>> more complicated than just gates) into a module. I can verify the
>>> operation of the module once, and use it many times.
>
>> MSI is a very basic functional block. If you are using this very often
>> you likely are working at a very low level.
>
>> The point is that it is not rocket science to code a shift register or
>> counter. There is very little value in being able to say you have a
>> verified counter module. Not much different than saying you have a
>> verified multiplexor module which you say you do in continuous assignments.
>
> If the design is already written in such blocks, it works well.
>
>> In the end, using such MSI components can be as error prone as writing
>> them from scratch. I avoid most errors in behavioral code by pulling up
>> an existing file and copying an arbitrary process for a registered
>> function and then editing the code. It also reduces the tedium. Then I
>> can focus on the specifics of what this function needs to do other than
>> be a register.
>
> (snip)
>
>>> As far as I know, some people like the way it looks more like a
>>> software (sequential) programming language.
>
>> Not sure what you mean by this. Only the guts of processes, procedures
>> and functions look and feel like a sequential language. I think we may
>> be talking about different things because you include continuous
>> assignments as "structural".
>
> OK, but continuous assignment isn't behavioral either.
>
> Behavioral has its own assignment.
I don't know what this means. Behavioral isn't part of an HDL language.
It refers to how you write your code. By instantiating low level
primitives you are defining your design by the gates used (even if the
tools will optimize that as it sees fit). Behavioral means you describe
what the logic does. You can only do structural using instantiation.
If you use concurrent assignments or processes to do anything other than
connect wires you are inferring logic based on a description of what it
does, not the gates it is made of.
>>>> Actually, I realize using structural code at the lower levels would be
>>>> *very* verbose because none of the higher level structural code is
>>>> reduced. So writing high and mid-level modules in structural code would
>>>> add lots of verbiage.
>
>>> Well, for example, I might write a multiplexer in a module, nice
>>> combinatorial logic with no registers, then use that module wherever
>>> I need a multiplexer, instead of rewriting one each time.
>
>> Yeah, that is the level of design that should be like falling off a log.
>> It is a one liner in a continuous assignment, five lines in a process
>> with two of them being ELSE and END IF;
>
>> Here is an example...
>
>> SineAmpWord <= LUT_Data when ('0' = PhaseSign) else - LUT_Data;
>
>> --- or ---
>> if ('0' = PhaseSign) then
>> SineAmpWord <= LUT_Data;
>> else
>> SineAmpWord <= - LUT_Data;
>> end if;
>
>> A great reason for inferring this logic is because the tools may decide
>> to skip the mux and use an adder with one input being a N bit bus of the
>> control signal saving a bunch of logic. If I hardwired it as a mux it
>> would not be as efficient and coding it this way I don't have to think
>> about it. Then again the tools would likely optimize it either way. lol
>
> The tools are pretty good. Sometimes a small mistake and half the
> logic gets optimized away.
>
>>> Internally, that module will use either the verilog conditional
>>> operator or VHDL WHEN operator. (Being use to C, I find the WHEN
>>> syntax a little strange, but it doesn't take long to get used to.)
>
>>> I suspect others will build a multiplexer using behavioral if
>>> statements in either language.
>
>>> OK, here is a multiplexer in VHDL:
>
>>> library IEEE;
>>> use IEEE.std_logic_1164.all;
>
>>> entity N157 is
>>> port (
>>> Y : out std_logic_vector(3 downto 0);
>>> A, B : in std_logic_vector(3 downto 0);
>>> S, G: std_logic);
>>> end entity N157;
>
>>> architecture N157 of N157 is
>>> begin
>>> Y <= X"0" when G='1' else A when S='0' else B;
>>> end architecture N157;
>
>> This is a terrible multiplexor module in VHDL. It is exactly 4 bits
>> wide when it could have been made N bits wide. Also it only works for
>> SLV data type when the example I use above will work for any types
>> available. BTW, what's with the name N157?
>
> It is the logic of the 74157.
>
>> Wouldn't it be better to
>> use something more descriptive? Otherwise, notice that all the work is
>> done in one line. Why go to all the trouble of the above when you only
>> need the one line?
>
>> Here is an example of a 5 to 1 mux by instantiation from a VHDL lecture.
>
>> --5:1 mux, 1 bit wide
>> LIBRARY ieee;
>> USE ieee.std_logic_1164.ALL;
>> LIBRARY adk;
>> USE adk.all;
>> ENTITY mux5_1_1wide IS
>> PORT(
>> a_input : IN STD_LOGIC; --input a
>> b_input : IN STD_LOGIC; --input b
>> c_input : IN STD_LOGIC; --input c
>> d_input : IN STD_LOGIC; --input d
>> e_input : IN STD_LOGIC; --input e
>> sel : IN STD_LOGIC_VECTOR(2 DOWNTO 0); --sel input
>> z_out : OUT STD_LOGIC --data out
>> );
>> END mux5_1_1wide;
>> ARCHITECTURE beh OF mux5_1_1wide IS
>> SIGNAL temp0, temp1, temp2, temp3 : STD_LOGIC;
>> COMPONENT mux21 PORT( a0,a1,s0 : IN STD_LOGIC;
>> y : OUT STD_LOGIC); END COMPONENT;
>> COMPONENT inv01 PORT( a : IN STD_LOGIC;
>> y : OUT STD_LOGIC); END COMPONENT;
>> BEGIN
>> U1 : mux21 PORT MAP(a0 => a_input,
>> a1 => b_input,
>> s0 => sel(0),
>> y => temp0);
>> U2 : mux21 PORT MAP(a0 => c_input,
>> a1 => d_input,
>> s0 => sel(0),
>> y => temp1);
>> U3 : mux21 PORT MAP(a0 => temp0,
>> a1 => temp1,
>> s0 => sel(1),
>> y => temp2);
>> U4 : mux21 PORT MAP(a0 => temp2,
>> a1 => e_input,
>> s0 => sel(2),
>> y => temp3);
>> U5 : inv01 PORT MAP(a => temp3,
>> y => z_out);
>> END beh;
>>
>> Using behavioral descriptions.
>>
>> --5:1 mux, 1 bit wide
>> LIBRARY ieee;
>> USE ieee.std_logic_1164.ALL;
>> LIBRARY adk;
>> USE adk.all;
>> ENTITY mux5_1_1wide IS
>> PORT(
>> a_input : IN STD_LOGIC; --input a
>> b_input : IN STD_LOGIC; --input b
>> c_input : IN STD_LOGIC; --input c
>> d_input : IN STD_LOGIC; --input d
>> e_input : IN STD_LOGIC; --input e
>> sel : IN STD_LOGIC_VECTOR(2 DOWNTO 0); --sel input
>> z_out : OUT STD_LOGIC --data out
>> );
>> END mux5_1_1wide;
>> ARCHITECTURE beh OF mux5_1_1wide IS
>> BEGIN
>> with sel select z_out <=
>> a_input when 0, -- count/2 = 1 for this choice
>> b_input when 1,
>> c_input when 2,
>> d_input when 3,
>> e_input when others;
>> END beh;
>
>> Which is simpler and more clear?
>
> If the logic is already written using such blocks, it is much easier
> to write VHDL from those blocks, and then verify that they look
> like the original design.
I don't understand. If the blocks were there, you don't need to write
anything. The above example illustrates how simpler behavioral code is
than structural code once you are working with higher levels of logic.
This is not even a very high level. Try structurally coding a UART with
full handshake controls and flags. A UART is a very simple IP block.
Then imagine coding a USB controller.
>> If you were coding something more
>> complex, would you really want to code it by assembling pieces rather
>> than just describing what it does? I had to use the schematic produced
>> by synthesis to see what was done in the case of sel > 4 so I could code
>> the behavioral logic the same.
>
> Also, as well as I know it, that isn't behavioral.
>
> For behavioral verilog it would look something like:
>
> always @(*) begin
> if (sel=0) then z_out <= a_input
> else if (sel=1) then z_out <= b_input
> else if (sel=2) then z_out <= c_input
> else if (sel=3) then z_out <= d_input
> else z_out <= e_input;
> end
>
> or I suppose the verilog case statement.
>
> The non-behavioral verilog form is:
>
> assign zout <= sel=0 ? a_input :
> sel=1 ? b_input :
> sel=2 ? c_input :
> sel=3 ? d_input :
> e_input :
Both of these are behavioral. You are describing how the circuit
behaves, not the gates used to implement it. The only difference is one
is continuous and the other is sequential.
Someone is giving you bad information. I hope this helps some.
--
Rick
Article: 158201Excuse me for a very long gap that I was absent. On Tue, 18 Aug 2015 21:40:27 -0400, Richard Damon wrote: > On 8/18/15 11:35 AM, rickman wrote: >> I'm not sure what details of the routing the chip editors leave out. >> You only need to know what is connected to what, through what and what >> the delays for all those cases are. Other than that, the routing does >> just "work". >> > Look closely. [...] Those rows and columns are made of a > (large) number of distinct wires with routing resources connecting > outputs to select lines and select lines being brought into the next > piece of routing/logic. Which wire is being used will not be indicated, > nor are all the wires interchangeable, so which wire can matter for > fitting. THIS is the missing information. A comment: All this information sounds like it can be teased out of the physical chips. But, I find there are other considerations. First, doing this might jeopardize the FPGA manufacturer. It's no good to have a FOSS toolchain but no FPGAs to use it on. Second, there is the problem of a FPGA manufacturer releasing a small tweak that would invalidate the entire work done. Third, and this is where it gets interesting, the time and effort spent reverse-engineering a great number of FPGA models is probably better spent engineering a FOSH ASIC toolchain together with the assorted manufacturing technology. Because - honestly - if you are willing to program FPGAs, you are really not very far away from forging ASICs, are you? Speaking for myself, I'm working alone on FPGAs far away from silicon powerhouses and I have to jump through hoops and loops to get the chips. Jumping through hoops and loops to get my design forged into an ASIC is not really that different.Article: 158202
rickman <gnuarm@gmail.com> wrote: (snip, I wrote) >> A lot of my VHDL assignments are putting together or taking apart >> vectors. It seems that VHDL feature is too new. So I have: >> y29 <= (a, b, c, d); >> -- instantiate entity using y29. > I am pretty sure you can use (a, b, c, d) in the component port map. > But there are some specific details on this and I haven't done much with > any HDL for a while so I've forgotten the finer points. (a, b, c, d) is > called and aggregate in VHDL. It seems that this changed over the years. As for Xilinx ISE, it works in the port for some devices, but not others. Doesn't make much sense, but they use a different VHDL parser for Spartan 3E and for Spartan 6. One allows it, one doesn't. Even newer in VHDL is the ability to do that in an output port. (or the left side of an assignment) like you could do in verilog for many years. But if can get a little ugly if not done carefully. -- glenArticle: 158203
rickman <gnuarm@gmail.com> wrote:
(snip)
> There is no difference between a concurrent assignment and a process
> with just one assignment and a sensitivity list with all input signals.
> In general, a process can have many assignments including variable vs.
> signals and the sensitivity list can include just a subset such as (clk,
> rst) for a clocked process.
(snip)
>> I suppose, but structural plus continuous assignment takes too
>> long to write.
> I don't follow. I thought you said that was what you do!
I mean the name of it takes too long to write. That is why I call
it structural, even though it is more.
(snip, I wrote)
>> OK, but continuous assignment isn't behavioral either.
>> Behavioral has its own assignment.
> I don't know what this means. Behavioral isn't part of an HDL language.
> It refers to how you write your code. By instantiating low level
> primitives you are defining your design by the gates used (even if the
> tools will optimize that as it sees fit). Behavioral means you describe
> what the logic does. You can only do structural using instantiation.
> If you use concurrent assignments or processes to do anything other than
> connect wires you are inferring logic based on a description of what it
> does, not the gates it is made of.
Behavioral model is inside verilog always blocks, and VHDL process
blocks, and yes it describes what the logic does.
(snip, I wrote)
>> If the logic is already written using such blocks, it is much easier
>> to write VHDL from those blocks, and then verify that they look
>> like the original design.
> I don't understand. If the blocks were there, you don't need to write
> anything. The above example illustrates how simpler behavioral code is
> than structural code once you are working with higher levels of logic.
> This is not even a very high level. Try structurally coding a UART with
> full handshake controls and flags. A UART is a very simple IP block.
> Then imagine coding a USB controller.
I am converting an existing design, made with TTL and such, into VHDL.
By following the TTL MSI blocks, I can do that with minimal thinking
and minimal mistakes. I don't have to understand what the logic does,
just be sure that what I write does the same thing as the original.
(snip, I wrote)
>> For behavioral verilog it would look something like:
>> always @(*) begin
>> if (sel=0) then z_out <= a_input
>> else if (sel=1) then z_out <= b_input
>> else if (sel=2) then z_out <= c_input
>> else if (sel=3) then z_out <= d_input
>> else z_out <= e_input;
>> end
>> or I suppose the verilog case statement.
>> The non-behavioral verilog form is:
>> assign zout <= sel=0 ? a_input :
>> sel=1 ? b_input :
>> sel=2 ? c_input :
>> sel=3 ? d_input :
>> e_input :
> Both of these are behavioral. You are describing how the circuit
> behaves, not the gates used to implement it. The only difference is one
> is continuous and the other is sequential.
> Someone is giving you bad information. I hope this helps some.
Well, I pretty much learned verilog from the Thomas and Moorby book,
and if you claim that they are wrong, many people will disagree.
They don't make it so obvious, but early on they have an example
of a 16 bit counter in structural model, which does include a
continuous assignment to indicate when the counter is about to
overflow.
Later on, they have a behavioral model counter, which doesn't
use continuous assignment, but with all the logic inside an
always block. The actual block looks something like:
always
begin
@(negedge clock) #10 value = value + 1;
if(value==15)
begin
altFifteen=1;
fifteen=1;
end
else
begin
altFifteen=0;
fifteen=0;
end
end
endmodule
They call it behavioral model, and so do I.
Note, for example, that the assignment are not continuous,
but only done with the appropriate if condition.
Well, read chapter 1 of Thomas and Moorby, and see what you think
qualifies as behavioral, or not behavioral, logic.
-- glen
Article: 158204On 12.09.2015 21:10, glen herrmannsfeldt wrote: > Tim Wescott <tim@seemywebsite.com> wrote: > (snip) >>> Evgeny Filatov <e.v.filatov@ieee.org> wrote: > >>>> I use graphical high-level tools to design DSP stuff and generate RTL >>>> for it. It works for me, but I started to suspect that it is more >>>> efficient to write RTL in HDL languages instead. > >> I'm assuming he means that he draws up a block diagram in Simulink and >> then pushes a button (well, maybe after lots of simulation and analysis). > >> But I'm just assuming. > > I do remember using schematic drawing tools, but most often found > it took a lot of work drawing lines, making sure that they didn't > overlap what they weren't supposed to, and otherwise getting it right. > > But I can write some lines of verilog or VHDL and not have to worry > about such lines overlapping. Match up signal names and everything > works the way it is supposed to. > > But I suppose something like simulink isn't so bad. Generate the > VHDL or verilog, look at it, and see if it looks right. > > -- glen > > Tim is correct. An example (GPS C/A stuff): http://tinyurl.com/nfmqjzm I just suck at writing in VHDL/verilog. Should practice more. Regards, Evgeny.Article: 158205
On 12/09/15 17:16, ecebharath@gmail.com wrote: > Hi, > > I am using eda playground.In which they provided the libraries to be included. > > Even after i have included the libraries also i am getting the error that is not finding the sc_signals class. Hi Bharath, did you notice that Hans was saying you may have misspelt sc_signal? The error message says sc_sgnal (no 'i'). regards Alan > > Thanks > Bharath > > > On Saturday, 12 September 2015 16:10:11 UTC+8, HT-Lab wrote: >> On 12/09/2015 05:48, ecebharath@gmail.com wrote: >>> Hi, >>> >>> I am getting below errors when i use systemc in edaplayground >>> >> I would suggest you compile your own local library as it will give you a >> more convenient and quicker working environment. Just google how to do it. >> >>> error: 'sc_sgnal' was not declared in this scope. >>> >> sc_signal? >> >> Hans >> www.ht-lab.com >> >>> I have added systemC2.3 library aswell. >>> >>> using C++ Copiler. >>> >>> Please help me >>> >>> Thanks >>> Bharath >>> > -- Alan FitchArticle: 158206
Evgeny Filatov <e.v.filatov@ieee.org> wrote: (snip, I wrote) >> I do remember using schematic drawing tools, but most often found >> it took a lot of work drawing lines, making sure that they didn't >> overlap what they weren't supposed to, and otherwise getting it right. >> But I can write some lines of verilog or VHDL and not have to worry >> about such lines overlapping. Match up signal names and everything >> works the way it is supposed to. (snip) > Tim is correct. An example (GPS C/A stuff): > http://tinyurl.com/nfmqjzm > I just suck at writing in VHDL/verilog. Should practice more. OK, the tools are surprisingly good at doing what needs to be done. If the problem is well described at the higher level, it is probably fine. If you need the highest speed, though, you might need to pipeline it, and that might not be so easy from the high level representation. If it is fast enough, and the high-level logic mostly does what you want, you might not need to worry. -- glenArticle: 158207
On 9/13/2015 5:34 PM, glen herrmannsfeldt wrote:
> rickman <gnuarm@gmail.com> wrote:
>
> (snip)
>
>> There is no difference between a concurrent assignment and a process
>> with just one assignment and a sensitivity list with all input signals.
>> In general, a process can have many assignments including variable vs.
>> signals and the sensitivity list can include just a subset such as (clk,
>> rst) for a clocked process.
>
> (snip)
>
>>> I suppose, but structural plus continuous assignment takes too
>>> long to write.
>
>> I don't follow. I thought you said that was what you do!
>
> I mean the name of it takes too long to write. That is why I call
> it structural, even though it is more.
Ok, but that means our conversation has mostly been one large
misunderstanding...
I think what you mean is you don't use processes other than for
describing specific registers or something like that.
>>> OK, but continuous assignment isn't behavioral either.
>
>>> Behavioral has its own assignment.
>
>> I don't know what this means. Behavioral isn't part of an HDL language.
>> It refers to how you write your code. By instantiating low level
>> primitives you are defining your design by the gates used (even if the
>> tools will optimize that as it sees fit). Behavioral means you describe
>> what the logic does. You can only do structural using instantiation.
>> If you use concurrent assignments or processes to do anything other than
>> connect wires you are inferring logic based on a description of what it
>> does, not the gates it is made of.
>
> Behavioral model is inside verilog always blocks, and VHDL process
> blocks, and yes it describes what the logic does.
There is the core of our misunderstanding. No one else I have found
uses that definition of "behavioral".
>>> If the logic is already written using such blocks, it is much easier
>>> to write VHDL from those blocks, and then verify that they look
>>> like the original design.
>
>> I don't understand. If the blocks were there, you don't need to write
>> anything. The above example illustrates how simpler behavioral code is
>> than structural code once you are working with higher levels of logic.
>> This is not even a very high level. Try structurally coding a UART with
>> full handshake controls and flags. A UART is a very simple IP block.
>> Then imagine coding a USB controller.
>
> I am converting an existing design, made with TTL and such, into VHDL.
> By following the TTL MSI blocks, I can do that with minimal thinking
> and minimal mistakes. I don't have to understand what the logic does,
> just be sure that what I write does the same thing as the original.
Sure, that is ideal for structural code. Duplicating something similar
to a schematic. But your definitions of the TTL components is most
likely to be behavioral. It is not too hard to design a 74x138 with
gates. The TI data sheet shows a schematic with 25 gates in it. Much
easier to do it with a simple with select statement inside an if as part
of a process.
>>> For behavioral verilog it would look something like:
>
>>> always @(*) begin
>>> if (sel=0) then z_out <= a_input
>>> else if (sel=1) then z_out <= b_input
>>> else if (sel=2) then z_out <= c_input
>>> else if (sel=3) then z_out <= d_input
>>> else z_out <= e_input;
>>> end
>
>>> or I suppose the verilog case statement.
>
>>> The non-behavioral verilog form is:
>
>>> assign zout <= sel=0 ? a_input :
>>> sel=1 ? b_input :
>>> sel=2 ? c_input :
>>> sel=3 ? d_input :
>>> e_input :
>
>> Both of these are behavioral. You are describing how the circuit
>> behaves, not the gates used to implement it. The only difference is one
>> is continuous and the other is sequential.
>
>> Someone is giving you bad information. I hope this helps some.
>
> Well, I pretty much learned verilog from the Thomas and Moorby book,
> and if you claim that they are wrong, many people will disagree.
>
> They don't make it so obvious, but early on they have an example
> of a 16 bit counter in structural model, which does include a
> continuous assignment to indicate when the counter is about to
> overflow.
>
> Later on, they have a behavioral model counter, which doesn't
> use continuous assignment, but with all the logic inside an
> always block. The actual block looks something like:
>
> always
> begin
> @(negedge clock) #10 value = value + 1;
> if(value==15)
> begin
> altFifteen=1;
> fifteen=1;
> end
> else
> begin
> altFifteen=0;
> fifteen=0;
> end
> end
> endmodule
>
> They call it behavioral model, and so do I.
Ok, but you really should read a bit more widely. You will find the
definition of "behavioral" has nothing to do with always blocks or
processes. It means the code is describing the behavior of the logic in
contrast to "structural" which is showing how blocks of logic are wired
together. "Continuous" assignments describe the behavior of the signal
they are assigned. They are equivalent to processes in all ways.
> Note, for example, that the assignment are not continuous,
> but only done with the appropriate if condition.
You are confusing "continuous" with non-behavioral. The assignments
work the same way regardless.
I can't speak for sure about Verilog, but I expect it works the same as
VHDL. "Continuous" assignments are the same as processes which have all
inputs to the assignment in the sensitivity list. This means the
process (or continuous assignment) does not run until one of the inputs
changes. Then the assignments are evaluated to produce an output which
may or may not have changed.
The fact that an IF is used in a process does not mean it is not
"continuous" in any mechanical sense. This is just a description of a
logic function. The signals in the IF statement are either assigned one
of two possible values (the THEN clause or the ELSE clause) or if no
assignment is included in one that infers a register or latch depending
on the outer logic (such as an IF clock or @(negedge clock)).
process (PhaseSign, LUT_Data) begin
if ('0' = PhaseSign) then
SineAmpWord <= LUT_Data;
else
SineAmpWord <= - LUT_Data;
end if;
end process;
This is exactly equivalent to this concurrent statement.
SineAmpWord <= LUT_Data when ('0' = PhaseSign) else - LUT_Data;
and to this Verilog always block I think...
always @ (in)
begin
if ('0' = PhaseSign) begin
SineAmpWord <= LUT_Data;
end else begin
SineAmpWord <= - LUT_Data;
end
end
or to this...
assign SineAmpWord <= ('0' = PhaseSign) ? LUT_Data : - LUT_Data;
There is no reason to distinguish between any of these functionally or
by thinking one runs "all the time" or any other meaning of the term
"continuous", even though some refer to it as if it truly were analyzed
"continuously".
> Well, read chapter 1 of Thomas and Moorby, and see what you think
> qualifies as behavioral, or not behavioral, logic.
I don't have that book. I have a few others on VHDL and none of them
say the term behavioral implies anything about the specifics of the
coding other than instantiation (structural) and inference (behavioral).
Try looking about the web. I am sure you will find tons of info on
this. I did and found a few Verilog references that use behavioral the
way you do, but they are not the majority.
I would say the terms structural and behavioral are not well or
certainly not consistently defined, so perhaps thy are poor terms to use.
--
Rick
Article: 158208On 9/13/2015 6:20 PM, Evgeny Filatov wrote: > On 12.09.2015 21:10, glen herrmannsfeldt wrote: >> Tim Wescott <tim@seemywebsite.com> wrote: >> (snip) >>>> Evgeny Filatov <e.v.filatov@ieee.org> wrote: >> >>>>> I use graphical high-level tools to design DSP stuff and generate RTL >>>>> for it. It works for me, but I started to suspect that it is more >>>>> efficient to write RTL in HDL languages instead. >> >>> I'm assuming he means that he draws up a block diagram in Simulink and >>> then pushes a button (well, maybe after lots of simulation and >>> analysis). >> >>> But I'm just assuming. >> >> I do remember using schematic drawing tools, but most often found >> it took a lot of work drawing lines, making sure that they didn't >> overlap what they weren't supposed to, and otherwise getting it right. >> >> But I can write some lines of verilog or VHDL and not have to worry >> about such lines overlapping. Match up signal names and everything >> works the way it is supposed to. >> >> But I suppose something like simulink isn't so bad. Generate the >> VHDL or verilog, look at it, and see if it looks right. >> >> -- glen >> >> > > Tim is correct. An example (GPS C/A stuff): > > http://tinyurl.com/nfmqjzm > > I just suck at writing in VHDL/verilog. Should practice more. Certainly VHDL can be verbose and it can present stumbling blocks to a newbie. I came from a world of schematics, so it isn't hard to impress me considering the huge improvement in productivity. If I ever find a good Verilog book, I will get more proficient with it. -- RickArticle: 158209
rickman wrote: > On 9/11/2015 11:42 PM, glen herrmannsfeldt wrote: >> I write structural verilog, or more recently structural VHDL. > > I'm not sure what you mean by that. Everyone writes structural HDL. > But they also write the code in the blocks that gets connected by the > structural HDL. Don't you? That is the hard part. > Well, at least in VHDL, there is structural and behavioral. Behavioral VHDL looks like a <= b or c; where structural looks like defining sub-components and then linking signals through their ports. So, you define 2-input OR gates, FF's and similar basic devices, and then wire them together with signals. JonArticle: 158210
On Sunday, May 24, 2015 at 1:41:07 AM UTC-7, Mark wrote: > Hello, > > I am looking for a module with Freescales iMX6 Solo and an FPGA, > maybe an Artix or similar. > Anyone know about such module? > For now no other requirements, I will look into details then. > > Thanks... > -- > Mark Lattice makes a IMX6 Solo with ECP5 FPGA running linux. If you can't find it, contact me. JimArticle: 158211
On 9/14/2015 3:01 PM, Jon Elson wrote: > rickman wrote: > >> On 9/11/2015 11:42 PM, glen herrmannsfeldt wrote: > >>> I write structural verilog, or more recently structural VHDL. >> >> I'm not sure what you mean by that. Everyone writes structural HDL. >> But they also write the code in the blocks that gets connected by the >> structural HDL. Don't you? That is the hard part. >> > Well, at least in VHDL, there is structural and behavioral. Behavioral VHDL > looks like > > a <= b or c; > > > where structural looks like defining sub-components and then linking signals > through their ports. So, you define 2-input OR gates, FF's and similar > basic devices, and then wire them together with signals. The confusion seems to come from the fact that a small number of Verilog texts and university materials use the terms for something other than what most of us use them for. Seems some use "behavioral" for code written in always blocks and "structural" for all other code. Most references use the term "behavioral" as you seem to be using it, for code that largely describes the behavior in code that is then used to infer the logic to implement the behavior. Structural code would be purely instantiating logic entities that exist. What ever the case, I think Glen and I understand each other. Glen doesn't like to use always blocks or processes and I am happy using them while minimizing my use of instantiation. -- RickArticle: 158212
On 14.09.2015 1:53, glen herrmannsfeldt wrote: > Evgeny Filatov <e.v.filatov@ieee.org> wrote: > > (snip, I wrote) > >>> I do remember using schematic drawing tools, but most often found >>> it took a lot of work drawing lines, making sure that they didn't >>> overlap what they weren't supposed to, and otherwise getting it right. > >>> But I can write some lines of verilog or VHDL and not have to worry >>> about such lines overlapping. Match up signal names and everything >>> works the way it is supposed to. > > (snip) > >> Tim is correct. An example (GPS C/A stuff): > >> http://tinyurl.com/nfmqjzm > >> I just suck at writing in VHDL/verilog. Should practice more. > > OK, the tools are surprisingly good at doing what needs to be done. > > If the problem is well described at the higher level, it is probably > fine. > > If you need the highest speed, though, you might need to pipeline it, > and that might not be so easy from the high level representation. > > If it is fast enough, and the high-level logic mostly does what > you want, you might not need to worry. > > -- glen > Thanks for the feedback, Glen, Rick, BobH and everyone else. I think I've understood that while it's no crime to use schematic tools, writing in VHDL/verilog offers greater flexibility and thus potential advantages in performance. Regards, Evgeny.Article: 158213
Fifo or SDRAM? It turned out to be the fifo. Data captured directly from fifo input/output showed that the problem is from the suspected fifo. It must be some sort of fifo ip internal failure of obscure nature. The issue also disappeared by reseting this fifo (using dedicated reset that does not reset anything else). The chosen remedy is to apply this reset immediately before any capture rather than redsign a fifo. There are many fifos in our design but only this one showed failure. Thanks for all your contributions. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158214
rickman wrote: >> >> I just suck at writing in VHDL/verilog. Should practice more. > > Certainly VHDL can be verbose and it can present stumbling blocks to a > newbie. I came from a world of schematics, so it isn't hard to impress > me considering the huge improvement in productivity. I dug myself a BIG hole about a decade ago, and I'm still recovering from the experience. I got into small-scale programmable hardware design with Xilinx CPLDs (9500 series) and used schematics, because these were really not typical designs. The first 9500 design was basically using the chips as a way to get hundreds of FFs, all with different clock sources in a small area. ONLY Xilinx could do this, other makers required all the FFs to be clocked from global clock lines. So, the 9500 was the perfect device for this very odd requirement. But, then, I realized the benefits of the CPLD and FPGA devices, and started using the Xilinx Foundation tools to enter schematics. I built the projects out of 8-bit FDC's, 8-bit tri-states and such components familiar to the 74xx logic designer. But, I hated the Aldec schematic tool in Foundation, and discovered my beloved Protel 99SE could make really NICE schematics, at about 4X the density of the Aldec ones, without the frustrating auto-line creation that drove me nuts! But, the Protel-created VHDL was not perfectly acceptable to Xilinx, I had to edit a few little bits in the files. So, then, instead of making all changes to the schematics, I started editing the computer- generated structural VHDL, which were VERY hard for a human to read. Hundreds of instances of inverters, gates and FFs, with lots of NetU107_O3 auto-generated net names and such. Slowly, over time, when a major change to one of these horrors was needed, I would completely recode it into behavioral VHDL, which was far more comprehensible, not to mention reducing 10+ pages of stuff to just a little more than one page! I still use structural VHDL for the top module, but now realize the huge error I made in doing all the schematics. Of course, part of the mistake was using a tool that "almost" worked. Also, Protel attempted to clone the schematic library parts from the Xilinx vcomp library, and apparently trained a secretary to enter all of them. I think they forgot to tell her those dots where lines crossed had any special meaning! So, I had to go in and correct about 50 of the library components, and then keep track of which ones had been fixed. Then, recently, I moved the hand-edited structural stuff to ise 13.4, and had CRAZY problems. I finally traced it to the definition of which inputs of partial-DeMorgan NOR gates were the inverted ones. I think on Ise 10, a NOR2B1 had the SECOND input inverted, on 13.4 the FIRST input is now the inverted one. Took a LONG time to guess that was what was going wrong. I ripped out all the deMorgan-type gates and placed explicit inverters. Well, I LEARNED something from the experience! (I hope!) JonArticle: 158215
Hi, My DisplayPort project has hit a speed bump - so close yet so far! Is there= anybody who knows DP and can can help me review things and bet me back on = track?=20 The AUX channel is up and running, EDID read, channel config works fine - a= t the moment I'm only bringing up one channel. Clock recovery, swing negotiation, pre-emphasis negotiation, symbol alignme= nt and lane alignment is all fine (verified though reading status registers= at 0x0020?). Once link is established, the idle pattern is sent for at least 64k cycles,= and then a clean switch over to the test 800x600 @ 60Hz stream. Monitor re= ports "No signal", but the high link stays up until monitor powers itself d= own (I'm polling the status registers every 500ms)..=20 * As per spec 512 BS symbols is being replaced by a SR symbol. * Main stream attributes are being sent during vertical blanking period.=20 * Tried with both scrambler enabled and disabled (with the corresponding re= gister setting on sink)- just in case there is an error in the scrambler to= o. * Verified 8b/10b coding using decoder from OpenCores, and by monitoring ru= nning disparity in simulation. * VB-ID, Mvid and Maud are being sent four times per BS symbol (as needed f= or a single lane). * BS (with bit 0 set in the VB-ID) are being sent during the vertical blank= ing interval, and on the last line of data. No BE symbols are being sent du= ring the vertical blank. I encode and send two symbols at a time (design is clocked at 135 MHz), and= suspect that the ordering over the physical layer could be an issue. I hav= e verified that the bits are going out in the order expected (if I swap the= LSB/MSB order the training pattern it fails). I have also tried swapping t= he order of symbols within the pairs, but with no success. So it seems to me that the sink is not able to reconstruct the pixel clock = and is giving up.=20 I'm using an 800x600@60 Hz, 24 bpp test pattern as the 40MHz pixel clock (1= 20M symbols per second) works in well with a 54-symbol TU, and each TU hold= ing 8 pixels worth of data.=20 * M value is 8 * N value is 54 * Pixel clock is 8 / 54 * 270M Hz =3D 40 MHz * MISC0 is set to indicate a a synchronous clock. * The Hstart and Vstart are the sums of the H & V sync width and back porch= . Because it all divides nicely I can build a test stream from a handful of T= U-sized blocks, and believe I am able to set Mvid[7:0] to be a constant 0x0= 4 following every BS symbol, just so it is different from Mvid during the i= dle pattern. I've looked at my simulations against random byte-level traces found on the= interweb (e.g. http://www.futureplus.com/download/presentation/dp_anal_at_= la.pdf) and have nothing unexplained, except why in the pdf the sync width = is showing as 16390, where the raw data (0x8006) indicate 6, with a active = low pulse, which is correct for 1024x768. What would be really helpful would be a short trace of a few known bytes (m= aybe the MSA attributes?), so I can check that my bits on the wire matches = in coding and ordering. What would also be helpful would be if somebody was able to look at a simul= ation of the test source (https://github.com/hamsternz/FPGA_DisplayPort/blo= b/master/src/test_source.vhd) and see if it makes sense as the main stream. I've got no access to high speed test gear, so everything is being checked = in simulation, and the Aux channel and status information (e.g. a blank sig= nal reconstructed by looking for BS, SR and BE codewords going into the tra= nsceiver) is begin monitored by a Saleae,=20 Any advice or an extra pair of eyes would be much appreciated! MikeArticle: 158216
Solution found.... M/N of 0x012F68/0x080000. Yay! Working DisplayPort! MikeArticle: 158217
BobH <wanderingmetalhead.nospam.please@yahoo.com> writes: > If you are using a good optimizing synthesis tool chain, the > difference may not be very large. I used some Mathcad generated RTL on > a project, and by the time the synthesis tool was done, it was as > tight as I could have gotten it by hand. Does Mathcad really have RTL generation these days? Or did you mean Matlab?Article: 158218
On 9/18/2015 2:14 AM, Anssi Saari wrote: > BobH <wanderingmetalhead.nospam.please@yahoo.com> writes: > >> If you are using a good optimizing synthesis tool chain, the >> difference may not be very large. I used some Mathcad generated RTL on >> a project, and by the time the synthesis tool was done, it was as >> tight as I could have gotten it by hand. > > Does Mathcad really have RTL generation these days? Or did you mean > Matlab? > You are correct, it is Matlab. I don't use either much anymore and always mix them up.Article: 158219
On 08.09.2015 20:52, Tim Wescott wrote: (snip) > After lurking for about a year you can answer > most questions by just regurgitating answers to previous questions.) > To employ the language of a poet, that's metaphorically like an LDPC code. The group has a sparse error-correcting matrix (meaning a lot of circularly shifted answers that may sound alike), but with that it achieves the goal of rapid error-correction and error-detection capability in the low SNR region (meaning producing good and fruitful answers to all the poorly formulated questions and/or mistaken propositions)! Evgeny.Article: 158220
On Wednesday, 23 September 2015 10:20:12 UTC+12, Evgeny Filatov wrote: > To employ the language of a poet, that's metaphorically like an LDPC > code. The group has a sparse error-correcting matrix (meaning a lot of > circularly shifted answers that may sound alike), but with that it > achieves the goal of rapid error-correction and error-detection > capability in the low SNR region (meaning producing good and fruitful > answers to all the poorly formulated questions and/or mistaken > propositions)! > > Evgeny. Inspired answer! +1Article: 158221
Hi, I see an example on Xilinx FPGA with tool Synplify-Pro: attribute syn_multstyle : string; attribute syn_multstyle of MULT : signal is "logic"; I only have Xilinx IDE. How can I get the above constraint in IDE? I am working on Xilinx Spartan-6. Thanks,Article: 158222
Hi, When I read a tutorial on FIR implementation on FPGA, I am not clear about "partial results can be used for many multiplications (regardless of symmetry)" That slide may be based on multiplier with logic cell in FPGA, not a dedicated MAC in FPGA. Anyhow, I don't know why 'partial results can be used for many multiplications (regardless of symmetry)'? I only think that to save 50% multiplier taking advantage of FIR coef symmetric characteristic. Could you tell me how to understand about the partial results? Thank,Article: 158223
>Hi, > >When I read a tutorial on FIR implementation on FPGA, I am not clear about > "partial results can be used for many multiplications (regardless of > symmetry)" That slide may be based on multiplier with logic cell in FPGA, >not > a dedicated MAC in FPGA. Anyhow, I don't know why 'partial results can be > used for many multiplications (regardless of symmetry)'? I only think that >to > save 50% multiplier taking advantage of FIR coef symmetric characteristic. > > >Could you tell me how to understand about the partial results? > >Thank, can we read that tutorial? Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158224
I have a product series that has mostly moved to Spartan 3A, but one member of the family is still using up boards made some time ago with the Spartan2E. I just found a mistake in all of the designs -- left out synchronizers on one input! I fixed the Spartan3A configurations, but no longer have a version of Ise 10 running. Looking through some files, I see there is a directory on my Ise 14.7 install - aISE_DS/ISE/spartan2e, so it seems at least some of the files needed to synthesize for the Spartan2E are there, but of course the main GUI doesn't allow you to select that family. (This is on a Linux system.) Does anyone know if Spartan2E can be synthesized on Ise 14.7 by re-enabling that family? I think I can probably boot up one of the archived hard drives that had Ise 10 on it if I have to, but that would be a bit of a pain. This should be a one-time need, just to get this one PROM file corrected. Thanks! Jon
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