Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

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

Custom Search

Messages from 158200

Article: 158200
Subject: Re: low-level vs. high-level
From: rickman <gnuarm@gmail.com>
Date: Sun, 13 Sep 2015 02:28:57 -0400
Links: << >>  << T >>  << A >>
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: 158201
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: Aleksandar Kuktin <akuktin@gmail.com>
Date: Sun, 13 Sep 2015 10:38:59 +0000 (UTC)
Links: << >>  << T >>  << A >>
Excuse 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
Subject: Re: low-level vs. high-level
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 13 Sep 2015 21:05:52 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.

-- glen

Article: 158203
Subject: Re: low-level vs. high-level
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 13 Sep 2015 21:34:05 +0000 (UTC)
Links: << >>  << T >>  << A >>
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: 158204
Subject: Re: low-level vs. high-level
From: Evgeny Filatov <e.v.filatov@ieee.org>
Date: Mon, 14 Sep 2015 01:20:52 +0300
Links: << >>  << T >>  << A >>
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.

Regards,
Evgeny.


Article: 158205
Subject: Re: I am getting errors when i run a systemC Code in edaplayground
From: Alan Fitch <apf@invalid.invalid>
Date: Sun, 13 Sep 2015 23:28:37 +0100
Links: << >>  << T >>  << A >>
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 Fitch

Article: 158206
Subject: Re: low-level vs. high-level
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 13 Sep 2015 22:53:36 +0000 (UTC)
Links: << >>  << T >>  << A >>
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

Article: 158207
Subject: Re: low-level vs. high-level
From: rickman <gnuarm@gmail.com>
Date: Sun, 13 Sep 2015 20:25:27 -0400
Links: << >>  << T >>  << A >>
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: 158208
Subject: Re: low-level vs. high-level
From: rickman <gnuarm@gmail.com>
Date: Sun, 13 Sep 2015 20:28:15 -0400
Links: << >>  << T >>  << A >>
On 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.

-- 

Rick

Article: 158209
Subject: Re: low-level vs. high-level
From: Jon Elson <jmelson@wustl.edu>
Date: Mon, 14 Sep 2015 14:01:06 -0500
Links: << >>  << T >>  << A >>
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.

Jon

Article: 158210
Subject: Re: IMX6 Solo - FPGA Module
From: jim.tavacoli@gmail.com
Date: Mon, 14 Sep 2015 14:20:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
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. 

Jim


Article: 158211
Subject: Re: low-level vs. high-level
From: rickman <gnuarm@gmail.com>
Date: Mon, 14 Sep 2015 18:04:25 -0400
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 158212
Subject: Re: low-level vs. high-level
From: Evgeny Filatov <e.v.filatov@ieee.org>
Date: Tue, 15 Sep 2015 01:26:18 +0300
Links: << >>  << T >>  << A >>
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
Subject: Re: fifo or sdram bug?
From: "kaz" <37480@FPGARelated>
Date: Tue, 15 Sep 2015 17:14:43 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 158214
Subject: Re: low-level vs. high-level
From: Jon Elson <jmelson@wustl.edu>
Date: Tue, 15 Sep 2015 17:33:43 -0500
Links: << >>  << T >>  << A >>
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!)

Jon

Article: 158215
Subject: Can anybody knowledgeable on DisplayPort help me?
From: Mike Field <mikefield1969@gmail.com>
Date: Wed, 16 Sep 2015 16:50:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
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!

Mike








Article: 158216
Subject: Can anybody knowledgeable on DisplayPort help me?
From: Mike Field <mikefield1969@gmail.com>
Date: Thu, 17 Sep 2015 00:16:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
Solution found.... M/N of 0x012F68/0x080000. Yay! Working DisplayPort!

Mike

Article: 158217
Subject: Re: low-level vs. high-level
From: Anssi Saari <as@sci.fi>
Date: Fri, 18 Sep 2015 12:14:12 +0300
Links: << >>  << T >>  << A >>
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
Subject: Re: low-level vs. high-level
From: BobH <wanderingmetalhead.nospam.please@yahoo.com>
Date: Fri, 18 Sep 2015 15:52:16 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Why is this group so quiet?
From: Evgeny Filatov <e.v.filatov@ieee.org>
Date: Wed, 23 Sep 2015 01:20:02 +0300
Links: << >>  << T >>  << A >>
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
Subject: Re: Why is this group so quiet?
From: Mike Field <mikefield1969@gmail.com>
Date: Wed, 23 Sep 2015 19:25:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
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! +1


Article: 158221
Subject: What equivalent attribute in Xilinx IDE
From: fl <rxjwg98@gmail.com>
Date: Fri, 25 Sep 2015 11:29:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Question about partial multiplication result in transposed FIR filter
From: fl <rxjwg98@gmail.com>
Date: Fri, 25 Sep 2015 13:10:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Question about partial multiplication result in transposed FIR filter
From: "kaz" <37480@FPGARelated>
Date: Fri, 25 Sep 2015 15:40:12 -0500
Links: << >>  << T >>  << A >>
>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.com

Article: 158224
Subject: Xilinx Spartan2E options?
From: Jon Elson <jmelson@wustl.edu>
Date: Fri, 25 Sep 2015 16:09:57 -0500
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

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

Custom Search