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
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 147250

Article: 147250
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Tue, 20 Apr 2010 15:38:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 20, 5:14=A0pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> On Apr 20, 11:46=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> > > >http://sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf
>
> > > The infamous Guideline #5 bans variable semantics from always blocks
> > > with sequential logic. It must be the Worst Guideline ever for RTL
> > > designers.
> > > The result is not wizardry but ignorance.
>
> > > How are we supposed to "raise the abstraction level" if Verilog RTL
> > > designers
> > > can't even use variables?
>
> > I didn't notice this post until today. =A0I think you are completely
> > misreading the guidelines if you think they mean "Verilog RTL
> > designers can't even use variables"
>
> I use that line as a shorthand for "Guideline #5 combined with
> Guideline #1, if taken seriously, forbids the use of traditional
> variable semantics provided by blocking assignments, in the
> context of a clocked always block".
>
> No matter how absurd I hope this sounds to you, that's really
> what it says.

Well, the guidelines absolutely _do_ "forbid the use of traditional
variable semantics provided by blocking assignments, in the context of
a clocked always block", but I don't think that translates into
"Verilog RTL designers can't even use variables."

What it *does* translate into is "The cleanest way to write Verilog is
somewhat verbose, in that it requires you to separate your
combinatorial logic from your sequential logic."

Basically, this method of thinking/coding requires two variables for
each sequential variable.  It's really handy to have a nice naming
convention, like next_x is the variable that will be placed into x on
the next clock.

So you have your definitions:

reg       y,  next_y;
reg [5:0] x,  next_x;

and your combinatorial block:

always @* begin
    next_x =3D x + 1;
    next_y =3D x =3D=3D 0;
end

and your sequential block:

always @(posedge clk or negedge rstn)
    if (!rstn) begin
        x <=3D 0;
        y <=3D 0;
    end else begin
        x <=3D next_x;
        y <=3D next_y;
    end

The declaration of registers and the sequential block both become,
pretty much, boilerplate code with this method of coding -- all the
action happens in the combinatorial block.  I am actually, slowly, in
my spare time, working on a project that will create a lot of the
boilerplate for coding in this method.

How does this help?  It's more about a human's ability to mentally
manage complexity than anything else.  In the sequential block, every
line must be 'xxx' <=3D next_'xxx'.  Very easy to verify.  In the
combinatorial block, 'next_' must appear on the lhs, and only on the
lhs, of any assignment involving a sequential variable.  Nothing keeps
you from using if, case statements, etc. in the combinatorial block,
and it's very easy to think about, because you see two variables
simultaneously -- what is 'x' right now, and what will 'x' be after
the next clock.

I have worked at several companies and with several individuals where
this coding style is used.  I did not invent it; as far as I know it
was probably invented at multiple places independently.  It works
quite well, but is, as I mentioned, a bit verbose.  There is no reason
to use it for extremely simple modules, but OTOH, the breakover point
where it is better to use it comes much sooner than you might think.

Regards,
Pat

Article: 147251
Subject: Re: Need to run old 8051 firmware
From: Derek Simmons <dereks314@gmail.com>
Date: Tue, 20 Apr 2010 18:14:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 19, 9:53=A0am, "Smith" <sm...@donotwantmail.com> wrote:
> Hello all
>
> I need to run an old firmware for a Siemens SAB 80C537 microcontroller un=
it
> (MCU). The MCU is now obsolete (it's from the late 1980s).
>
> The firmware is compiled from several thousand rows of assembly language.=
 It
> would take a long time to understand the code and re-program it in C.
>
> So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware
> code without any changes to the code.
>
> Any one here had any luck with this kind of problem?

The 8031/8051 architecture or compatible MCUs are still being used.
When I was at KODAK it was used in a couple of different parts of a
minilab system for controlling and synchronizing motors. I recently
interviewed with a avionics company that uses it for digital displays
in the cockpit of the plane (it is easy to get certfied for the FAA).

Don't write it off yet...

Derek

Article: 147252
Subject: Virtex 7?
From: "stephen.craven@gmail.com" <stephen.craven@gmail.com>
Date: Tue, 20 Apr 2010 18:20:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
The CTO of Xilinx, during his keynote this morning at the
Reconfigurable Architectures Workshop in Atlanta, made mention of the
recent announcement of the Virtex 7 architecture.  My colleagues and I
assumed that either the announcement was very recent or not very well
publicized as none of us had heard anything official regarding Virtex
7. A subsequent web search returned little except for a white paper on
28nm technology.

Does anyone know what announcement the CTO was referring to?

Article: 147253
Subject: Re: Need to run old 8051 firmware
From: Chris H <chris@phaedsys.org>
Date: Wed, 21 Apr 2010 08:25:08 +0100
Links: << >>  << T >>  << A >>
In message <1771ba54-e12f-44ba-af73-1cebb0cb2182@11g2000yqr.googlegroups
.com>, Derek Simmons <dereks314@gmail.com> writes
>On Apr 19, 9:53†am, "Smith" <sm...@donotwantmail.com> wrote:
>> Hello all
>>
>> I need to run an old firmware for a Siemens SAB 80C537 microcontroller unit
>> (MCU). The MCU is now obsolete (it's from the late 1980s).
>>
>> The firmware is compiled from several thousand rows of assembly language. It
>> would take a long time to understand the code and re-program it in C.
>>
>> So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware
>> code without any changes to the code.
>>
>> Any one here had any luck with this kind of problem?
>
>The 8031/8051 architecture or compatible MCUs are still being used.
>When I was at KODAK it was used in a couple of different parts of a
>minilab system for controlling and synchronizing motors. I recently
>interviewed with a avionics company that uses it for digital displays
>in the cockpit of the plane (it is easy to get certfied for the FAA).
>
>Don't write it off yet...

There are some 500 variants based on over 40 different cores.  Whilst it
is relatively easy to move C it will be a real dog to moves assembler.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/




Article: 147254
Subject: Xilinx no longer ships with Modelsim MXE?
From: "HT-Lab" <hans64@ht-lab.com>
Date: Wed, 21 Apr 2010 09:19:10 +0100
Links: << >>  << T >>  << A >>
I received a Sigasi Editor update email which had the following statement:

"Xilinx no longer ships ModelSim with ISE but now ships its own HDL simulator 
that enables functional and timing simulations for VHDL, Verilog and mixed 
VHDL/Verilog designs: ISim."

Is this correct?

Although ISIM is not bad it is still a long way from being Modelsim (even though 
the MXE(starter) edition is fairly limited),

Hans
www.ht-lab.com



Article: 147255
Subject: Re: Need to run old 8051 firmware
From: Tilmann Reh <usenet2007nospam@autometer.de>
Date: Wed, 21 Apr 2010 11:09:19 +0200
Links: << >>  << T >>  << A >>
Chris H schrieb:

>>The 8031/8051 architecture or compatible MCUs are still being used.
>>When I was at KODAK it was used in a couple of different parts of a
>>minilab system for controlling and synchronizing motors. I recently
>>interviewed with a avionics company that uses it for digital displays
>>in the cockpit of the plane (it is easy to get certfied for the FAA).
>>
>>Don't write it off yet...
> 
> There are some 500 variants based on over 40 different cores.  Whilst it
> is relatively easy to move C it will be a real dog to moves assembler.

It does depend on programming /style/ more than on programming /language/.

If the device-related code (peripherals, special functions) is spread
over all sources, with inline access/instructions and not commented,
it's *much* work regardless of language.

If the code is well structured and commented, with modules dedicated to
clearly defined tasks, it's not really a problem - also regardless of
language.

Tilmann

Article: 147256
Subject: Re: I'd rather switch than fight!
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Wed, 21 Apr 2010 11:02:40 +0100
Links: << >>  << T >>  << A >>
>> The point is that if you don't do static timing analysis (or have an
>> analyzer that is broken) timing verification is nearly impossible.
>
> And even if you do, the device might still have timing problems.


Can you expand on this Glen?

As I have always understood it one of the bedrocks of FPGA design is that
when it's passed a properly constrained static timing analysis an FPGA design
will always work (from a timing point of view).



Nial.





Article: 147257
Subject: Re: Efficient Multi-Ported Memories for FPGAs
From: John_H <newsgroup@johnhandwork.com>
Date: Wed, 21 Apr 2010 03:26:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 20, 1:00=A0pm, Eric <eric.lafor...@gmail.com> wrote:
> Hi All,
>
> I've recently published a paper exploring how to implement memories
> with multiple read and write ports on existing FPGAs. I figured it
> might be of interest to some.
>
> Summary, paper, slides, and example code are here:http://www.eecg.utoront=
o.ca/~laforest/multiport/index.html
>
> There are no patents or other additional IP encumbrances on the code.
> If you have any comments or other feedback, I'd like to hear it.
>
> Eric LaForest
> PhD student, ECE Dept.
> University of Torontohttp://www.eecg.utoronto.ca/~laforest/

Could you mention here or on your page what you mean by
"multipumping?"  If you mean time multiplexed access, I can see why
multipumping is bad.  [The "pure logic" approach also isn't obvious.]

Do you update the LVT in the same way I might update the RAM value in
a many-write BlockRAM?  To implement a many-write BlockRAM, each
"write bank" is maintained separately.  To write a new value, only the
write bank for the associated write port is updated but with the XOR
of the write data with the reads for all the other write banks at the
same address.  By reading the same address from all write banks, the
XOR of all the reads is the most recent write value (unless there are
multiple writes in the same clock cycle).  Since the LVT only has to
be as wide as the number of entries, I can see how this would be very
beneficial for wide data and many write ports.

Aside from wide data, however, I don't see (without going into the
attachments on that page) how updating the LVT is any different than
updating the memory in the first place.

Article: 147258
Subject: Re: Need to run old 8051 firmware
From: Chris H <chris@phaedsys.org>
Date: Wed, 21 Apr 2010 12:00:45 +0100
Links: << >>  << T >>  << A >>
In message <hqmfbt$g77$1@news.eternal-september.org>, Tilmann Reh
<usenet2007nospam@autometer.de> writes
>Chris H schrieb:
>
>>>The 8031/8051 architecture or compatible MCUs are still being used.
>>>When I was at KODAK it was used in a couple of different parts of a
>>>minilab system for controlling and synchronizing motors. I recently
>>>interviewed with a avionics company that uses it for digital displays
>>>in the cockpit of the plane (it is easy to get certfied for the FAA).
>>>
>>>Don't write it off yet...
>>
>> There are some 500 variants based on over 40 different cores.  Whilst it
>> is relatively easy to move C it will be a real dog to moves assembler.
>
>It does depend on programming /style/ more than on programming /language/.
>
>If the device-related code (peripherals, special functions) is spread
>over all sources, with inline access/instructions and not commented,
>it's *much* work regardless of language.
>
>If the code is well structured and commented, with modules dedicated to
>clearly defined tasks, it's not really a problem - also regardless of
>language.

For a high level language I would agree but we are discussing "several
thousand rows of assembly language".

For most 8051 code the C will be the same for the core and it is only
the peripherals that are different. Most of the other stuff like memory
allocation and SFR's etc will be handled by the compiler.  A recompile
with a different 8051 target  selected will solve many of the problems.
With Assembler you can't do that.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/




Article: 147259
Subject: Re: I'd rather switch than fight!
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 21 Apr 2010 11:36:14 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga Nial Stewart <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote:
>>> The point is that if you don't do static timing analysis (or have an
>>> analyzer that is broken) timing verification is nearly impossible.

>> And even if you do, the device might still have timing problems.
 
> Can you expand on this Glen?
 
> As I have always understood it one of the bedrocks of FPGA design 
> is that when it's passed a properly constrained static timing 
> analysis an FPGA design will always work (from a timing point of view).

Well, some of the comments were regarding ASIC design, where
things aren't so sure.  For FPGA designs, there is, as you say,
"properly constrained" which isn't true for all design and tool
combinations.   One that I have heard of, though haven't actually
tried, is having a logic block where the delay is greater than
one clock cycle, but less than two.  Maybe some tools can do that,
but I don't believe that all can.

-- glen



Article: 147260
Subject: Re: Xilinx no longer ships with Modelsim MXE?
From: Marc Guardiani <news.guardiani@gmail.com>
Date: Wed, 21 Apr 2010 06:16:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 21, 4:19=A0am, "HT-Lab" <han...@ht-lab.com> wrote:
> I received a Sigasi Editor update email which had the following statement=
:
>
> "Xilinx no longer ships ModelSim with ISE but now ships its own HDL simul=
ator
> that enables functional and timing simulations for VHDL, Verilog and mixe=
d
> VHDL/Verilog designs: ISim."
>
> Is this correct?
>
> Although ISIM is not bad it is still a long way from being Modelsim (even=
 though
> the MXE(starter) edition is fairly limited),
>
> Hanswww.ht-lab.com

Interesting. Altera is taking exactly the opposite approach. The first
time I started Quartus II v9.1 SP1 I got a message that said their
native simulator would not be included "in future versions" of the
software. Talking with my FAE, he stated that starting with version
10.0 only ModelSim-Altera would be included.

--Marc

Article: 147261
Subject: Re: I'd rather switch than fight!
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Wed, 21 Apr 2010 06:19:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 21, 12:38=A0am, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 20, 5:14=A0pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:
>
>
>
> > On Apr 20, 11:46=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> > > > >http://sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf
>
> > > > The infamous Guideline #5 bans variable semantics from always block=
s
> > > > with sequential logic. It must be the Worst Guideline ever for RTL
> > > > designers.
> > > > The result is not wizardry but ignorance.
>
> > > > How are we supposed to "raise the abstraction level" if Verilog RTL
> > > > designers
> > > > can't even use variables?
>
> > > I didn't notice this post until today. =A0I think you are completely
> > > misreading the guidelines if you think they mean "Verilog RTL
> > > designers can't even use variables"
>
> > I use that line as a shorthand for "Guideline #5 combined with
> > Guideline #1, if taken seriously, forbids the use of traditional
> > variable semantics provided by blocking assignments, in the
> > context of a clocked always block".
>
> > No matter how absurd I hope this sounds to you, that's really
> > what it says.
>
> Well, the guidelines absolutely _do_ "forbid the use of traditional
> variable semantics provided by blocking assignments, in the context of
> a clocked always block", but I don't think that translates into
> "Verilog RTL designers can't even use variables."
>
> What it *does* translate into is "The cleanest way to write Verilog is
> somewhat verbose, in that it requires you to separate your
> combinatorial logic from your sequential logic."
>
> Basically, this method of thinking/coding requires two variables for
> each sequential variable. =A0It's really handy to have a nice naming
> convention, like next_x is the variable that will be placed into x on
> the next clock.
>
> So you have your definitions:
>
> reg =A0 =A0 =A0 y, =A0next_y;
> reg [5:0] x, =A0next_x;
>
> and your combinatorial block:
>
> always @* begin
> =A0 =A0 next_x =3D x + 1;
> =A0 =A0 next_y =3D x =3D=3D 0;
> end
>
> and your sequential block:
>
> always @(posedge clk or negedge rstn)
> =A0 =A0 if (!rstn) begin
> =A0 =A0 =A0 =A0 x <=3D 0;
> =A0 =A0 =A0 =A0 y <=3D 0;
> =A0 =A0 end else begin
> =A0 =A0 =A0 =A0 x <=3D next_x;
> =A0 =A0 =A0 =A0 y <=3D next_y;
> =A0 =A0 end
>
> The declaration of registers and the sequential block both become,
> pretty much, boilerplate code with this method of coding -- all the
> action happens in the combinatorial block. =A0I am actually, slowly, in
> my spare time, working on a project that will create a lot of the
> boilerplate for coding in this method.
>
> How does this help? =A0It's more about a human's ability to mentally
> manage complexity than anything else. =A0In the sequential block, every
> line must be 'xxx' <=3D next_'xxx'. =A0Very easy to verify. =A0In the
> combinatorial block, 'next_' must appear on the lhs, and only on the
> lhs, of any assignment involving a sequential variable. =A0Nothing keeps
> you from using if, case statements, etc. in the combinatorial block,
> and it's very easy to think about, because you see two variables
> simultaneously -- what is 'x' right now, and what will 'x' be after
> the next clock.
>
> I have worked at several companies and with several individuals where
> this coding style is used. =A0I did not invent it; as far as I know it
> was probably invented at multiple places independently. =A0It works
> quite well, but is, as I mentioned, a bit verbose. =A0There is no reason
> to use it for extremely simple modules, but OTOH, the breakover point
> where it is better to use it comes much sooner than you might think.

Thanks for explaining your coding style details, that's much
more enlightening than philosophical discussions.

I stand by my quote. The context was clearly "using variables to
raise the abstraction level". That's not what this does.

Your coding style provides a very verbose workaround for temporary
variables. I just can't imagine this is how you do test benches, that
are presumably much more complex than your RTL code. Presumably
there you use temporary variables directly where you need them without
great difficulty. Why would it have to be so different for
synthesizable
RTL?

You refer to a "mental model" to manage complexity. To your credit,
you provide an argument, something the original author of
guideline #5 never did. However, I find it dubious. To manage
complexity,
I don't need to see the hardware registers, complete with Q and D,
so explicitly in the code. I think I understand pretty well what kind
of
coding styles are efficiently supported by synthesis tools. Given
this,
I try to write the code itself as clearly as possible.

Most importantly: your coding style doesn't support non-temporary
variables. In other words, register inferencing from variables is not
supported and therefore ignored as technique. In this sense, this is
actually a good illustration of the point I'm trying to make.

I happen to think that register inferencing from variables is an
essential tool. It raises the abstraction level just one notch. The
registers are not glancing at you from the code (although
unambiguously defined) but in return your coding style can be
much more expressive.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Article: 147262
Subject: Re: Xilinx no longer ships with Modelsim MXE?
From: General Schvantzkoph <schvantzkoph@yahoo.com>
Date: 21 Apr 2010 13:58:12 GMT
Links: << >>  << T >>  << A >>
On Wed, 21 Apr 2010 09:19:10 +0100, HT-Lab wrote:

> I received a Sigasi Editor update email which had the following
> statement:
> 
> "Xilinx no longer ships ModelSim with ISE but now ships its own HDL
> simulator that enables functional and timing simulations for VHDL,
> Verilog and mixed VHDL/Verilog designs: ISim."
> 
> Is this correct?
> 
> Although ISIM is not bad it is still a long way from being Modelsim
> (even though the MXE(starter) edition is fairly limited),
> 
> Hans
> www.ht-lab.com

Has anyone here tried the Xilinx simulator? How is it's performance 
relative to commercial simulators? 

Modelsim Starter is severely crippled so it wouldn't be a particularly 
hard task to produce a simulator that out performs it. Both Xilinx and 
Altera of produced synthesis tools that are competitive with Synplify, it 
would be interesting if Xilinx had ambitions to produce a simulator that 
was as fast as Questa, or better yet as fast as NCsim.

Article: 147263
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Wed, 21 Apr 2010 07:34:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 21, 8:19=A0am, Jan Decaluwe <j...@jandecaluwe.com> wrote:

> Thanks for explaining your coding style details, that's much
> more enlightening than philosophical discussions.
>
> I stand by my quote. The context was clearly "using variables to
> raise the abstraction level". That's not what this does.

I didn't show any variables raising the abstraction level, no, but I
showed a context they could be provided in.

> Your coding style provides a very verbose workaround for temporary
> variables. I just can't imagine this is how you do test benches, that
> are presumably much more complex than your RTL code. Presumably
> there you use temporary variables directly where you need them without
> great difficulty. Why would it have to be so different for
> synthesizable
> RTL?

You're right.  Testbenches do not suffer from this limitation.  But,
in point of fact, I can use any sort of logic in my testbench.  I use
constructs all the time that aren't realistically synthesizable, so
comparing how I code synthesizable RTL vs how I code testbenches would
turn up a lot more differences than just this.

> You refer to a "mental model" to manage complexity. To your credit,
> you provide an argument, something the original author of
> guideline #5 never did. However, I find it dubious. To manage
> complexity,
> I don't need to see the hardware registers, complete with Q and D,
> so explicitly in the code. I think I understand pretty well what kind
> of
> coding styles are efficiently supported by synthesis tools. Given
> this,
> I try to write the code itself as clearly as possible.

Yes, but when you use if/else, or case statements, or other complex
structures, it is easy to get lost.  Humans can only hold a very few
things in their minds at a time, and this is a powerful tool.  As I
said, I certainly did not invent this style, but I personally know
dozens of people who use it, and I have personally introduced it to at
least 3 people, and they all find it extremely useful.

> Most importantly: your coding style doesn't support non-temporary
> variables. In other words, register inferencing from variables is not
> supported and therefore ignored as technique. In this sense, this is
> actually a good illustration of the point I'm trying to make.

Well, it may be a good illustration to you, but now you're waxing
philosophical again.  Care to show an example (preferably in verilog)
of how not using this coding style supports your preferred technique?

> I happen to think that register inferencing from variables is an
> essential tool. It raises the abstraction level just one notch. The
> registers are not glancing at you from the code (although
> unambiguously defined) but in return your coding style can be
> much more expressive.

I am actually doing something similar, I think, in my verilog
automagic boilerplate code, which can determine size and type of
registers in most cases, and automatically declares them.

Regards,
Pat

Article: 147264
Subject: Re: Xilinx Pipelined/Streaming FFT Architecure?
From: "onkars" <onkars@n_o_s_p_a_m.n_o_s_p_a_m.winlab.rutgers.edu>
Date: Wed, 21 Apr 2010 10:52:15 -0500
Links: << >>  << T >>  << A >>

Any information in this regard will be really appreciated.


>
>I guess Xilinx also uses R2^2SDF --- because they have scaling for every
>pair of radix 2 butterflies.
>
>>
>>Altera clearly mentions that their pipelined FFT core uses R2^2SDF
>>architecture.
>>But I could not find any such info about Xilinx -- can anyone help?
>>
>>Onkar
>>
>>>Hi,
>>>
>>>Can anyone tell me whether the Xilinx Pipelined FFT arch uses R2SDF or
>>>R2^2SDF?
>>>
>>>Regards,
>>>Onkar
>>>
>>>	   
>>>					
>>>---------------------------------------		
>>>Posted through http://www.FPGARelated.com
>>>	   
>>					
>>---------------------------------------		
>>Posted through http://www.FPGARelated.com
>>	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147265
Subject: Polmaddie Family CPLD and FPGA Teaching Boards
From: John Adair <g1@enterpoint.co.uk>
Date: Wed, 21 Apr 2010 08:59:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
We finally made an assembly slot and built the 4 remaining Polmaddie
CPLD and FPGA boards. These very low cost CPLD and FPGA boards will
sell to universities and colleges in prices as low as $30-40. One off
pricing starts at $60-70.

The concept is a bit different to that offered by most development
board vendors and we have 5 solutions, from 4 different CPLD/FPGA
vendors, allowing you to evaluate differnt tool flows or even
different technologies with a common feature set.

More details http://www.enterpoint.co.uk/polmaddie/polmaddie_family.html.

Polmaddie1 is shipping already. Polmaddie 3 should start shipping next
week. Polmaddie2 should be shipping next. We are doing a low cost USB
programmer for this board and that is a 2-3 weeks away. Polmaddie4 and
Polmaddie5 will be a little longer as we need to do some work on low
cost programming solutions for them.

John Adair
Enterpoint Ltd.

Article: 147266
Subject: Re: Virtex 7?
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 21 Apr 2010 09:15:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 20, 6:20=A0pm, "stephen.cra...@gmail.com"
<stephen.cra...@gmail.com> wrote:
> The CTO of Xilinx, during his keynote this morning at the
> Reconfigurable Architectures Workshop in Atlanta, made mention of the
> recent announcement of the Virtex 7 architecture. =A0My colleagues and I
> assumed that either the announcement was very recent or not very well
> publicized as none of us had heard anything official regarding Virtex
> 7. A subsequent web search returned little except for a white paper on
> 28nm technology.
>
> Does anyone know what announcement the CTO was referring to?

Either your colleagues misheard what was said our our CTO, Ivo Bolson,
mispoke.  There has been no announcement of a Virtex-7 FPGA family.

Xilinx did recently announce aspects of future families that will be
developed on the 28nm process node.
http://www.xilinx.com/technology/roadmap/index.htm

Ed McGettigan
--
Xilinx Inc.

Article: 147267
Subject: Re: Xilinx no longer ships with Modelsim MXE?
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 21 Apr 2010 09:19:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 21, 1:19=A0am, "HT-Lab" <han...@ht-lab.com> wrote:
> I received a Sigasi Editor update email which had the following statement=
:
>
> "Xilinx no longer ships ModelSim with ISE but now ships its own HDL simul=
ator
> that enables functional and timing simulations for VHDL, Verilog and mixe=
d
> VHDL/Verilog designs: ISim."
>
> Is this correct?
>
> Although ISIM is not bad it is still a long way from being Modelsim (even=
 though
> the MXE(starter) edition is fairly limited),
>
> Hanswww.ht-lab.com

Xilinx still provides ModelSim XE (Xilinx Edition),
http://www.xilinx.com/tools/mxe.htm

Ed McGettigan
--
Xilinx Inc

Article: 147268
Subject: Re: Need to run old 8051 firmware
From: Tilmann Reh <usenet2007nospam@autometer.de>
Date: Wed, 21 Apr 2010 18:29:02 +0200
Links: << >>  << T >>  << A >>
Chris H schrieb:

>>It does depend on programming /style/ more than on programming /language/.
>>
>>If the device-related code (peripherals, special functions) is spread
>>over all sources, with inline access/instructions and not commented,
>>it's *much* work regardless of language.
>>
>>If the code is well structured and commented, with modules dedicated to
>>clearly defined tasks, it's not really a problem - also regardless of
>>language.
> 
> For a high level language I would agree but we are discussing "several
> thousand rows of assembly language".

Even with several ten thousands rows of assembler that needs not be a
problem. BTDT. It's a matter of structure and documentation. (I am still
doing many projects completely in assembler.)

> For most 8051 code the C will be the same for the core and it is only
> the peripherals that are different. Most of the other stuff like memory
> allocation and SFR's etc will be handled by the compiler.  A recompile
> with a different 8051 target  selected will solve many of the problems.
> With Assembler you can't do that.

Even with C you need to access the SFRs (ports, peripherals) somehow. If
these accesses are splattered across the whole sources, it doesn't
matter if it's C or assembler.

Memory allocation is normally uncritical, since that is easily portable
between many similar derivatives. Of course, if you previously had a
device with large XRAM (being used indeed) and try to port that to a
smaller chip, you'll run into problems... But again, in this case C
wouldn't help you either.

Basically, the part that you can leave unchanged with C, is the same
part that you can leave unchanged with assembler.

Tilmann

Article: 147269
Subject: Synplify synthesis error
From: "ilaroche" <isabellelaroche@n_o_s_p_a_m.gmail.com>
Date: Wed, 21 Apr 2010 13:34:07 -0500
Links: << >>  << T >>  << A >>
Hello everyone, 

I'm trying to synthesise my design using Synplify Pro D-2010, but I am new
to this tool and encountering various problems. Here's my first one, which
I'd like to solve to be able to investigate other mysterious errors I'm
getting. 

In my design, I use a package called "types_viterbi". In my VHDL files, I
access this package by using the classic "use work.types_viterbi.all" line
of code. The file containing this package is added to my Synplify project.
I see it under the VHDL folder in the GUI shown when accessing my .prj
file. 

Except, when I try to do a "Synthax Check" or a "Synthesis Check" of my
components, Synplify returns a warning saying it cannot find
"types_viterbi". So, of course, it cannot find the constants I've declared
in this package, which is the error shown below. Here's the exact warning &
error returned by Synplify: 


@W: CD643
:"U:\Recherche\Algo_Viterbi_Parallele\VHDL\Synplify\source\decodeur_viterbi_carre.vhd":11:21:11:21|Ignoring
use clause - types_viterbi not found ... 
@E: CD255
:"U:\Recherche\Algo_Viterbi_Parallele\VHDL\Synplify\source\decodeur_viterbi_carre.vhd":15:42:15:42|No
identifier "poids_size" in scope 



I've read the documentation related to the compiler warning CD643, and it
says nothing about user-defined packages. However, in the Synplify
documentation on Libraries and Package, there's the following information :



If you create your own package and compile it into the work library to
access its definitions, you still need a use clause before the entity using
them, but not a library clause (because work is the default library.) 
To access packages other than those in work and std, you must provide a
library and use clause for each package as shown in the following example
of creating a resource library. 



Is there a step I must do to compile my package into the work library? I've
tried selecting the "types_viterbi.vhd" file and running the "Compile
Only/F7" command, but this compiles the top_level entity. I did another
Check Syntax of the top level entity after, and I still got the warning &
error. Yet, the compile command worked!  I haven't tried compiling my
package into a separate library. It would involve changing all of my VHDL
files to include this new library and I'd rather just have access to my
package from the work library. 

Any help clarifying this problem is welcomed. Again, I'm new to this tool,
so it may be a very simple solution, but I can't find anything in their
documentation or on a Google search.

Sincerly,

Isabelle LaRoche
Université Laval 


	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147270
Subject: multiboot spartan3E
From: "bouthouri" <hatem.win@n_o_s_p_a_m.hotmail.fr>
Date: Wed, 21 Apr 2010 13:34:14 -0500
Links: << >>  << T >>  << A >>
I will use Intel StrataFlash Parallel NOR Flash PROM to store two . bit
files

I have been able to generate the two files. prm &. mcs after having
1) prepare a PromFile.
2) Prom supporting multiple Design versions .
3) Adding the first and the second Bitsream bitsream


after that I want to configure the parallel Prom but I can not make it? is
what I have to configure the FPGA as or NO?? ...

Can someone help me??? thank you in advance .. 	
	


	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147271
Subject: Re: Polmaddie Family CPLD and FPGA Teaching Boards
From: Patrick Maupin <pmaupin@gmail.com>
Date: Wed, 21 Apr 2010 11:44:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 21, 10:59=A0am, John Adair <g...@enterpoint.co.uk> wrote:
> We finally made an assembly slot and built the 4 remaining Polmaddie
> CPLD and FPGA boards. These very low cost CPLD and FPGA boards will
> sell to universities and colleges in prices as low as $30-40. One off
> pricing starts at $60-70.
>
> The concept is a bit different to that offered by most development
> board vendors and we have 5 solutions, from 4 different CPLD/FPGA
> vendors, allowing you to evaluate differnt tool flows or even
> different technologies with a common feature set.
>
> More detailshttp://www.enterpoint.co.uk/polmaddie/polmaddie_family.html.
>
> Polmaddie1 is shipping already. Polmaddie 3 should start shipping next
> week. Polmaddie2 should be shipping next. We are doing a low cost USB
> programmer for this board and that is a 2-3 weeks away. Polmaddie4 and
> Polmaddie5 will be a little longer as we need to do some work on low
> cost programming solutions for them.
>
> John Adair
> Enterpoint Ltd.

I didn't see which Spartan-3 is on the Polmaddie 3.

Thanks,
Pat

Article: 147272
Subject: Re: Polmaddie Family CPLD and FPGA Teaching Boards
From: John Adair <g1@enterpoint.co.uk>
Date: Wed, 21 Apr 2010 12:13:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
It is a XC3S50AN on the Polmaddie3 so it's quite a useful board even
beyond the target of the educational market. It's my personal
favourite of the 5 boards but they all have different things to show.

It is worth saying all of these boards can be powered from the USB
port and the jack on board is just for convenience.

John Adair
Enterpoint Ltd.

On 21 Apr, 19:44, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 21, 10:59=A0am, John Adair <g...@enterpoint.co.uk> wrote:
>
>
>
> > We finally made an assembly slot and built the 4 remaining Polmaddie
> > CPLD and FPGA boards. These very low cost CPLD and FPGA boards will
> > sell to universities and colleges in prices as low as $30-40. One off
> > pricing starts at $60-70.
>
> > The concept is a bit different to that offered by most development
> > board vendors and we have 5 solutions, from 4 different CPLD/FPGA
> > vendors, allowing you to evaluate differnt tool flows or even
> > different technologies with a common feature set.
>
> > More detailshttp://www.enterpoint.co.uk/polmaddie/polmaddie_family.html=
.
>
> > Polmaddie1 is shipping already. Polmaddie 3 should start shipping next
> > week. Polmaddie2 should be shipping next. We are doing a low cost USB
> > programmer for this board and that is a 2-3 weeks away. Polmaddie4 and
> > Polmaddie5 will be a little longer as we need to do some work on low
> > cost programming solutions for them.
>
> > John Adair
> > Enterpoint Ltd.
>
> I didn't see which Spartan-3 is on the Polmaddie 3.
>
> Thanks,
> Pat


Article: 147273
Subject: Re: Synplify synthesis error
From: Pontus <pontus.stenstrom@gmail.com>
Date: Wed, 21 Apr 2010 12:27:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
Does it simulate OK?

Sometimes the files need to be added in correct order, i.e.
the file with the package must be added before any library
units that make use of it. IIRC you can drag them around in the
gui to alter the order, or check the .prj file which should have
lines such as:
add_file -lib work my_pkg.vhd
add_file -lib work my_ent.vhd
etc.

HTH -- Pontus

Article: 147274
Subject: Re: Xilinx no longer ships with Modelsim MXE?
From: Anssi Saari <as@sci.fi>
Date: Wed, 21 Apr 2010 22:40:08 +0300
Links: << >>  << T >>  << A >>
"HT-Lab" <hans64@ht-lab.com> writes:

> Although ISIM is not bad it is still a long way from being Modelsim (even though 
> the MXE(starter) edition is fairly limited),

I dunno, but I was still able to download the latest Modelsim MXE from
Xilinx today, version 6.4b from 04/06/2009. But considering it's
fairly old, maybe it's true. I'm sure Xilinx is very happy if they can
stop stuffing Mentor's coffers and ship their own ISIM instead.



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
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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