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 46525

Article: 46525
Subject: Re: synthesizing hard coded numbers
From: Mike Treseler <tres@tc.fluke.com>
Date: Mon, 02 Sep 2002 11:32:32 -0700
Links: << >>  << T >>  << A >>
jan wrote:

> Hello.

> The reg statement will probably syntehsize into RAM on the FPGA, the
> initial statement will not synthesize at all ( I'm using Leonardo
> targeting Altera's FLEX devices).


Initialization does not work for synthesis.
Use a reset input.

         -- Mike Treseler


Article: 46526
Subject: Re: Hardware Code Morphing?
From: Jan-Hinnerk Reichert <jan-hinnerk_reichert.NO-SPAMt@hamburg.de>
Date: Mon, 02 Sep 2002 21:14:20 +0200
Links: << >>  << T >>  << A >>
Kunal wrote:

> I read about Transmeta's Crusoe chip some time back, which has
> something called the Code Morphing Software. This code morphing s/w
> actually reads hex from its code memory, and at run-time translates
> the hex code into equivalent native machine language instructions. So
> the whole system itself is like a Java Virtual Machine (or a run-time
> cross-assembler), only there is no partitioning between the H/W and
> the system S/W.
> 
> The whole thing is a overhead, of course, but its highly optimized and
> parallelized in hardware wherever possible. Last I read, they had code
> morphing software for 8086 instructions, i.e the Code Morphing
> Software could only "understand" 86 hex. This system also allows you
> to run programs compiled for different processors at the same time,
> i.e it decides at run-time which instruction set is supported.
> 
> Ok here's an idea... how about code-morphing HARDWARE?

This sounds crazy enough to be interesting ;-)

[...]
>
> Of course, there are a LOT of issues here, and operation may be slowed
> down slightly, but it IS possible. The biggest problem would be
> mapping between specific registers, but we can leave that to the
> application programmer or the source assembler / compiler.

IMHO the biggest problem is the PC (program counter) mapping.

The straight forward approach is to simulate every virtual instruction with 
the same number of real instructions. If the processor you are emulating
has multiplication builtin in and your micro hasn't that can be quite a lot.
You would do a jump to skip the unused part in simpler instructions.
- This is easy to implement only needs a EPROM as lookup-table
- This has overhead of a jump for almost all instructions
- This wastes much of the available address space

Second approach:
Use a call for each instruction
- almost as simple to implement
- greater overhead (call/ret) per instruction
- maximum usage of address space
- simple instructions may not need a call

Third approach:
Mix both. Do all commands that are quite short (perhaps 4 words) directly. 
Do a call for the rest.
- still doable with a few standard logic parts (74xxx)

Another thought:
Using variable length replacements is very difficult, because you have to 
analyse the whole program and make a PC translation table. I wouldn't do 
that.

> The applications of such a device would be very interesting indeed. A
> code-morph for Java bytecode is only the beginning....  Backward
> Compatibility will not be an issue anymore. This, I understand, is
> keeping them from using all the features on the latest Intel chips. We
> can load protocol-translation mappings to, transperently converting
> from, say RS-232 to I2C (we already have hardware TCP/IP stacks). We
> could port the hex code itself to other processors, instead of
> re-writing the source code and re-compiling. Programmers can include
> useful language features from other instructions sets without having
> to worry about implementing them in the target processor code.
> 
> Ok that's enough speculation for now, but could anyone well-versed in
> VLSI design tell me how feasible this is? I don't think it will be
> very difficult to implement, but the design of such a chip would be
> very challenging. Also I need to know from experienced embedded
> systems designers how truly useful such a device would be, and would
> all the effort of developing it pay off, in terms of financial returns
> and intellectual property rights.

Or would there be lots of Transmeta lawyers hunting you down?

I think you are better of with a software VM:
- you can use uC without external program memory (more choices)
- you can run all code from internal memory (more speed)
- you can use a chip with harvard architecture (more speed)

The hardware VM could be faster if most instructions can be simulated
by one or two instrauctions. But remember the wait states you have to add 
for the translation logic.

At last: Would it be cheaper to buy the hardware VM or to buy a faster 
processor?

Still it would be a great fun project.

The reason that it works for Transmeta is that their processor is designed 
to do this.

> kundi


Article: 46527
Subject: Re: Hardware Code Morphing?
From: Robin KAY <komadori@myrealbox.com>
Date: Mon, 02 Sep 2002 20:34:10 +0100
Links: << >>  << T >>  << A >>
Falk Brunner wrote:

> I never understood what the hell is the advantage of putting some kind of
> realtime compiler into expensive silliy-cone? Wouldnt those Transmeta guys
> be much smarter (and nowadays much richer) if the had done a nice optimiced
> RISC or whatever CPU and wrote a "simple" piece of software "aka translator,
> compiler whatever) to translate a x86 code to native RISC just before
> executing it, then load the RISC-code into RAM and execute it.? Anyone can
> enlighten me?

That is very much akin to what they did do. The Crusoe core is 4 issue VLIW
implementation that runs the "Code Morphing" software loaded from a Flash-ROM
on the mainboard. The software takes care of code translation, branch
prediction, register renaming, and instruction reordering largely in software
although the Crusoe does have some specialized hardware to speed this up.

--
Wishing you good fortune,
--Robin Kay-- (komadori)



Article: 46528
Subject: Re: Hardware Code Morphing?
From: Terje Mathisen <terje.mathisen@hda.hydro.com>
Date: Mon, 02 Sep 2002 21:46:11 +0200
Links: << >>  << T >>  << A >>
Falk Brunner wrote:
> "Kunal" <kundi_forever@yahoo.com> schrieb im Newsbeitrag
> news:cd714c44.0209020625.5b892675@posting.google.com...
> 
> [Code morphing in microprocessors and FPGAs ]
> 
> I never understood what the hell is the advantage of putting some kind of
> realtime compiler into expensive silliy-cone? Wouldnt those Transmeta guys
> be much smarter (and nowadays much richer) if the had done a nice optimiced
> RISC or whatever CPU and wrote a "simple" piece of software "aka translator,
> compiler whatever) to translate a x86 code to native RISC just before
> executing it, then load the RISC-code into RAM and execute it.? Anyone can
> enlighten me?

A key idea:

To work in the x86-compatibility market, the cpu must be capable of 
booting multiple OSs, which means that the translator had to be internal 
to the cpu.

The pure sw emulation approach was tried with DECs FX-32 (sp?), it 
worked OK for applications but could never handle an OS.

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"


Article: 46529
Subject: Re: Hardware Code Morphing?
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Mon, 2 Sep 2002 19:52:31 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3D73BD32.F3295793@myrealbox.com>,
Robin KAY  <komadori@myrealbox.com> wrote:
>That is very much akin to what they did do. The Crusoe core is 4 issue VLIW
>implementation that runs the "Code Morphing" software loaded from a Flash-ROM
>on the mainboard. The software takes care of code translation, branch
>prediction, register renaming, and instruction reordering largely in software
>although the Crusoe does have some specialized hardware to speed this up.

The problem is by putting the compiler in the inner loop, you have a
pretty severe penalty for misses in the translation cache.  As such,
they were going for performance and lost (it's hard to statically
schedule for a 4 issue VLIW when translating from x86, and the in
order design is so penalized on the minor cache misses).

Since they failed on performance, they tried to make claims about
power.  The problem is, this puts them directly up against Intel's
fabrication facilities.  If ultra low power x86 really mattered, intel
would process shrink the Pentium core.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 46530
Subject: Re: Hardware Code Morphing?
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Mon, 2 Sep 2002 19:54:04 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <al0f65$evv$1@vkhdsu24.hda.hydro.com>,
Terje Mathisen  <terje.mathisen@hda.hydro.com> wrote:
>The pure sw emulation approach was tried with DECs FX-32 (sp?), it 
>worked OK for applications but could never handle an OS.

Well, it handled MOST of the OS, IIRC.  I seem to recall the portable
NT relying very heavily on a 486 emulator.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 46531
Subject: Re: Hardware Code Morphing?
From: nmm1@cus.cam.ac.uk (Nick Maclaren)
Date: 2 Sep 2002 20:13:14 GMT
Links: << >>  << T >>  << A >>
In article <al08lg$1litsf$1@ID-84877.news.dfncis.de>,
Falk Brunner <Falk.Brunner@gmx.de> wrote:
>"Kunal" <kundi_forever@yahoo.com> schrieb im Newsbeitrag
>news:cd714c44.0209020625.5b892675@posting.google.com...
>
>[Code morphing in microprocessors and FPGAs ]
>
>I never understood what the hell is the advantage of putting some kind of
>realtime compiler into expensive silliy-cone? Wouldnt those Transmeta guys
>be much smarter (and nowadays much richer) if the had done a nice optimiced
>RISC or whatever CPU and wrote a "simple" piece of software "aka translator,
>compiler whatever) to translate a x86 code to native RISC just before
>executing it, then load the RISC-code into RAM and execute it.? Anyone can
>enlighten me?

Effectively, that is what they do.  N decades of experience is that
typical application-level ISAs are ghastly for programming fast
emulators in, so what you want is a RISC ISA specifically designed
for executing emulators.  Then you put the emulator into firmware
as a mixture of a just-in-time compiler and run-time emulation.
Firmware/microcode/whatever is cheap silicon!

This approach is in common to both the Crusoe and Pentium 4; they
have made different choices of detail, but they have a lot in
common.  As most readers will remember, I believe that this
approach is grossly underutilised, and could be used (for example)
to produce much more streamlined arithmetic units (and hence more
and faster ones).


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

Article: 46532
Subject: Re: Hardware Code Morphing?
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Mon, 2 Sep 2002 20:19:42 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <al0goq$1mp$1@pegasus.csx.cam.ac.uk>,
Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
>Effectively, that is what they do.  N decades of experience is that
>typical application-level ISAs are ghastly for programming fast
>emulators in, so what you want is a RISC ISA specifically designed
>for executing emulators.  Then you put the emulator into firmware
>as a mixture of a just-in-time compiler and run-time emulation.
>Firmware/microcode/whatever is cheap silicon!

Effectively all performance oriented x86s do translation to an
internal representation.  AMD athlon's require 3 pipeline stages,
IIRC.  But both AMD and Intel are translating to out of order cores,
while transmeta is inorder.  Since so many x86 instructions touch
memory, this can hurt transmeta.

Also, intel, by cacheing the translations, decided they could make the
tranlater slower (1 op/cycle as opposed to 3), which magnifies the
icache miss penalty.  IN retrospect, probably not the right decision.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 46533
Subject: Re: Hardware Code Morphing?
From: z80@ds1.com (Peter)
Date: Mon, 02 Sep 2002 21:33:04 +0100
Links: << >>  << T >>  << A >>

nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote

>Since they failed on performance, they tried to make claims about
>power.  The problem is, this puts them directly up against Intel's
>fabrication facilities.  If ultra low power x86 really mattered, intel
>would process shrink the Pentium core.

It appears that the Transmeta laptops don't offer significantly better
battery life - when you compare MHz for MHz.

I have done a fair bit of very low power ASIC development work, and it
amazes me that, after all these years of CMOS, we still have a "CMOS"
CPU, in a PC which 99% of the time does NOTHING (waits for a
keystroke) and yet the damn thing still dissipates several WATTS!!

I expect these CPUs are not anywhere near fully static CMOS, but ...


Peter.
--
Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.

Article: 46534
Subject: Re: Hardware Code Morphing?
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Mon, 2 Sep 2002 20:51:13 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <98i7nu83nln4ge0dbrdmimda24074kqa8g@4ax.com>,
Peter <z80@ds1.com> wrote:
>>Since they failed on performance, they tried to make claims about
>>power.  The problem is, this puts them directly up against Intel's
>>fabrication facilities.  If ultra low power x86 really mattered, intel
>>would process shrink the Pentium core.
>
>It appears that the Transmeta laptops don't offer significantly better
>battery life - when you compare MHz for MHz.

They do have some better power management (better than Intel's "Fast
or Slow" model in the P3 low power core), but then again, if low power
performance MATTERED in the x86 world, you do what StrongARM did:

Build a fully static, in order, processor, and process shrink it as
much as you can.  Intel has such great fab technology that you could
probably do a 1-2 W, 1 GHz x86 that way.

Also, Amdahl's law keeps Transmeta down, only about 1/3 of the
notebook power budget is to the processor.

>I have done a fair bit of very low power ASIC development work, and it
>amazes me that, after all these years of CMOS, we still have a "CMOS"
>CPU, in a PC which 99% of the time does NOTHING (waits for a
>keystroke) and yet the damn thing still dissipates several WATTS!!

>I expect these CPUs are not anywhere near fully static CMOS, but ...

Nowhere even close.  :)

It's CMOS only in transitior types, not design methodology.

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 46535
Subject: C/C++ to Verilog/VHDL ?!
From: "Frank Andreas de Groot" <nospam@nospam.com>
Date: Mon, 02 Sep 2002 21:30:11 GMT
Links: << >>  << T >>  << A >>
Hi,

Has anyone experience with C++ to Verilog/VHDL convertors?
I thought that as a C++ programmer and a total FPGA newbie with just a
minimum of
digital design experience, this avenue would be very interesting, especially
because
I seek to implement a medium-complex software algorithm into a FPGA, and
this algorithm will be subject to gradual refinement.

I specifically would like to know:

1) Price
2) Capability ( in terms of supported C/C++)
3) Capability ( in terms of what it can produce)
4) Efficiency in using the FPGA resources.

I already looked at those products:

http://www.forteds.com/products/cynthesizer.html
http://www.synopsys.com/products/cocentric_systemC/cocentric_systemC.html

But they seem incredibly expensive and it is very hard to judge the
capabilities from their websites.

Thanks for any enlightenment,

Frank de Groot, Oslo



Article: 46536
Subject: Re: C/C++ to Verilog/VHDL ?!
From: "Frank Andreas de Groot" <nospam@nospam.com>
Date: Mon, 02 Sep 2002 21:39:46 GMT
Links: << >>  << T >>  << A >>
OOPS.

<sigh> I guess that's that then...

"C2Verilog 2.0 is available now on Unix and Windows platforms starting at
$75,000."

Frank


"Frank Andreas de Groot" <nospam@nospam.com> wrote in message
news:DLQc9.17039$sR2.303475@news4.ulv.nextra.no...

> I specifically would like to know:
>
> 1) Price




Article: 46537
Subject: Re: synthesizing hard coded numbers
From: "Stan" <vze3qgji@verizon.net>
Date: Mon, 02 Sep 2002 21:40:06 GMT
Links: << >>  << T >>  << A >>

"Mike Treseler" <tres@tc.fluke.com> wrote in message
news:3D73AEC0.6010508@tc.fluke.com...
> jan wrote:
>
> > Hello.
>
> > The reg statement will probably syntehsize into RAM on the FPGA, the
> > initial statement will not synthesize at all ( I'm using Leonardo
> > targeting Altera's FLEX devices).
>
>
> Initialization does not work for synthesis.
> Use a reset input.
>
>          -- Mike Treseler

Yeah, you probably want something like:

reg [11:0] sR;

always @(posedge clk) begin
  if (reset)  sR[11:0] <= 12'h6AD;
  else sR[11:0] <= { sR[0], sR[11:1] };
end

That will rotate the data one bit each clock.  If you want to pad with
zeroes, use { 1'b0, sR[11:1] } .
(Real hardware guys don't use "shift". )  :-)

-Stan




Article: 46538
Subject: Re: high-speed design rule on FPGAs?
From: "Stan" <vze3qgji@verizon.net>
Date: Mon, 02 Sep 2002 21:41:44 GMT
Links: << >>  << T >>  << A >>
In general the fastest logic will only have a simple equation between flip
flop stages.  -Stan

"Arguo" <s9323090@cc.ncu.edu.tw> wrote in message
news:52758910.0209020319.70d66511@posting.google.com...
> I designed an SDRAM controller by Verilog using in Altera APEX20KE.
> But the timing analyser report tell me, the crtical path is about 15ns.
> I think that my Verilog module design is not good. Maybe too combine
logic.
> Which book or reference can tell me how to do design high-speed logic?
>
> Best Regards



Article: 46539
Subject: Re: Hardware Code Morphing?
From: sfp@mpeltd.demon.co.uk (Stephen Pelc)
Date: Mon, 02 Sep 2002 21:51:36 GMT
Links: << >>  << T >>  << A >>
On 2 Sep 2002 07:25:59 -0700, kundi_forever@yahoo.com (Kunal) wrote:

>A pretty challenging VLSI project actually, possible too. Here's how I
>think it may work:
>This Code Morphing (CM) chip would be placed on the bus in between the
>target uC and the code memory (ROM, flash wotever). It would route the
>addresses generated by the uC to the code memory, and translate the
>returned contents into hex code of the target uC, and send the
>translated version back to the uC. This is pretty much what the JVM
>does, but this virtual machine is a HARDWARE virutal machine, i.e. the
>mapping between various instruction sets is HARD-WIRED.

This topic is extensively covered in the following book:
  Interpretation and Instruction Path Coprocessing
  Eddy H. Debaere and Jan M. van Campenhout
  MIT Press, 1990
  ISBN 0-262-04107-3

Several languages are discussed.

Stephen

--
Stephen Pelc, sfp@mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

Article: 46540
Subject: Re: C/C++ to Verilog/VHDL ?!
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 03 Sep 2002 10:40:19 +1200
Links: << >>  << T >>  << A >>
Frank Andreas de Groot wrote:
> 
> Hi,
> 
> Has anyone experience with C++ to Verilog/VHDL convertors?
> I thought that as a C++ programmer and a total FPGA newbie with just a
> minimum of
> digital design experience, this avenue would be very interesting, especially
> because
> I seek to implement a medium-complex software algorithm into a FPGA, and
> this algorithm will be subject to gradual refinement.

 C/C++, and other sequential/procedural languages are 
'one thing at a time/one place at a time' languages, and 
so do not map/utilize well onto FPGA resource.

 You need to look carefully at your medium-complex software algorithm,
and decide if it can benefit from parallel execution.

 If not, then a procedural language Compiler to a Soft Core 
running on a FPGA would be a valid path. 
 Soft cores are improving all the time, and I believe you can now
add you own opcodes - this allows some 
'subroutine function -> HW replacement'

 If the algorithm can benefit from parallel execution, then look 
to use a SW langauge that is implicitly parallel to code it.

 If VHDL does not look suitable, a new language (AsmL) that I think
has good promise to blur the Sw/HW boundary is at

http://www.research.microsoft.com/fse/asml/overview.html

 This is free, and you could use it to experiment with.

 A softcore that swallows .NET bytecodes is probably not far off...

 - jg

Article: 46541
Subject: Re: synthesizing hard coded numbers
From: John_H <johnhandwork@mail.com>
Date: Mon, 02 Sep 2002 16:16:12 -0700
Links: << >>  << T >>  << A >>
Too many of these shift elements and the resources get a bit ugly for a 
distributed register scheme;  the approach is fine for a few 
coefficients and easy to understand from a code-support standpoint.

If you want many fixed values, you should be able to appease both 
simulation and synthesis by generating lookup tables.  Rather than using 
shift registers which would need discrete registers for each bit in most 
of the Altera families (I think the Stratix has shift register memory 
elements), use a ROM type approach where you should end up with only one 
  LE per coefficient.  By generating your own bit index and defining the 
values in a way that both simulation and synthesis can use, the whole 
task folds together nicely.  The Index is input to each LE and the 
single registered output bit is your result.  I haven't tested the code 
but I think it makes sense.

reg  [11:0] Coeff [2:0];
reg  [ 3:0] Index;
wire [ 4:0] next_index;
integer i;
reg [2:0] SRout;

always
begin
   Coeff[0] = 12'b011010101101;
   Coeff[1] = 12'h1a5;
   Coeff[2] = 12'd3192;
end
always @(posedge clock)
begin
   if( next_index[4] )  Index <= 4'd11;  // if next index is -1, reload
   else Index <= next_index;
   for( i=0; i<3; i=i+1 )
     SRout[i] <= Coeff[i] >> Index;
end
assign next_index = Index - 1;

Real hardware guys already have their shift together.

- John_H



Stan wrote:

> "Mike Treseler" <tres@tc.fluke.com> wrote in message
> news:3D73AEC0.6010508@tc.fluke.com...
> 
>>jan wrote:
>>
>>
>>>Hello.
>>>
>>>The reg statement will probably syntehsize into RAM on the FPGA, the
>>>initial statement will not synthesize at all ( I'm using Leonardo
>>>targeting Altera's FLEX devices).
>>>
>>
>>Initialization does not work for synthesis.
>>Use a reset input.
>>
>>         -- Mike Treseler
>>
> 
> Yeah, you probably want something like:
> 
> reg [11:0] sR;
> 
> always @(posedge clk) begin
>   if (reset)  sR[11:0] <= 12'h6AD;
>   else sR[11:0] <= { sR[0], sR[11:1] };
> end
> 
> That will rotate the data one bit each clock.  If you want to pad with
> zeroes, use { 1'b0, sR[11:1] } .
> (Real hardware guys don't use "shift". )  :-)
> 
> -Stan
> 
> 
> 
> 


Article: 46542
Subject: Re: C/C++ to Verilog/VHDL ?!
From: "Frank Andreas de Groot" <nospam@nospam.com>
Date: Tue, 03 Sep 2002 00:10:52 GMT
Links: << >>  << T >>  << A >>
LOL

Yes, I understand that it's a waste of hardware opportunities to code in C,
and have it translated to a crappy Verilog equivalent...

In the FPGA should be something like a 64-bit tri-state counter that gets an
initial value
from a PCI bus, and a pattern recognizer that looks at the output and
advances the counter
when it sees certain pattern combinations.
All in all quite complex I'm afraid, too complex for a newbie.

To write it in C though, would not be such a big problem at all for me.
I would spend months testing and debugging the C, but then at least I'd have
a (slow and inefficient)
Verilog representation that I can refine, analize the hardware equivalent
etc.

I will look into your suggestions.
I have seen exactly what I need, and it seems to be available for free too,
but they don't offer it for download any more, it's called CTOV from Tenison
Tech:

http://www.tenisontech.com/products/ctov-page.html

Very sad...
But maybe I should just stop whining and learn how to do it the right way...

Frank


"Jim Granville" <jim.granville@designtools.co.nz> wrote in message
news:3D73E8D3.279B@designtools.co.nz...
>
>  If VHDL does not look suitable, a new language (AsmL) that I think
> has good promise to blur the Sw/HW boundary is at
>

>
>  This is free, and you could use it to experiment with.
>
>  A softcore that swallows .NET bytecodes is probably not far off...
>
>  - jg



Article: 46543
Subject: Re: Actel Proto Boards
From: jerry@quickcores.com (Jerry D. Harthcock)
Date: 2 Sep 2002 17:28:58 -0700
Links: << >>  << T >>  << A >>
"Josh Model" <model@ll.mit.edu> wrote in message news:<wkc89.44$I7.3516@llslave.llan.ll.mit.edu>...
> Has anyone come across any 3rd party prototype boards for Actel FPGA's?
> It seems as if Actel's stuff starts at ~$1k, and I was looking for one
> closer to the $500 range.
> 
> Thanks,
> --Josh

QuickCores offers a low cost IP Delivery System based on Actel's new
ProASIC+.
Prices start at $175 for the APA075.  It's all self-contained in that
no external device programmer is required.  It also includes a
built-in JTAG boundary scan controller and built-in JTAG real-time
debug controller for microcontroller designs.  No JTAG pod is required
since everything is done via RS-232 using Actel Libero-generated STAPL
files.

It's all packaged in a 28-pin postage stamp form factor for easy
prototyping.  It's called the Musketeer (All-for-One Stamp).

Visit www.quickcores.com for info.

Regards,

Jerry

Article: 46544
Subject: Re: Actel Proto Boards
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 03 Sep 2002 13:19:02 +1200
Links: << >>  << T >>  << A >>
Jerry D. Harthcock wrote:
> 
> "Josh Model" <model@ll.mit.edu> wrote in message news:<wkc89.44$I7.3516@llslave.llan.ll.mit.edu>...
> > Has anyone come across any 3rd party prototype boards for Actel FPGA's?
> > It seems as if Actel's stuff starts at ~$1k, and I was looking for one
> > closer to the $500 range.
> >
> > Thanks,
> > --Josh
> 
> QuickCores offers a low cost IP Delivery System based on Actel's new
> ProASIC+.
> Prices start at $175 for the APA075.  It's all self-contained in that
> no external device programmer is required.  It also includes a
> built-in JTAG boundary scan controller and built-in JTAG real-time
> debug controller for microcontroller designs.  No JTAG pod is required
> since everything is done via RS-232 using Actel Libero-generated STAPL
> files.
> 
> It's all packaged in a 28-pin postage stamp form factor for easy
> prototyping.  It's called the Musketeer (All-for-One Stamp).
> 
> Visit www.quickcores.com for info.

 Interesting lineup.

 What if a designer wants to mix some FPGA HW design, with one of 
 your soft-cores ? - how is that done ?

 Missing from the web, is any speed info on these cores ?

 - jg

-- 
======= 80x51 Tools & IP Specialists  =========
= http://www.DesignTools.co.nz

Article: 46545
Subject: Re: MicroBlaze processor core
From: jerry@quickcores.com (Jerry D. Harthcock)
Date: 2 Sep 2002 20:50:56 -0700
Links: << >>  << T >>  << A >>
"Holger Venus" <Holger.Venus@dlr.de> wrote in message news:<aji8kt$1ai94m$1@ID-143082.news.dfncis.de>...
> Hi all,
> does any body has experience with embedded processor IP cores in FPGA?
.
.
> Thanks for any (related) comment,
> 
> Holger Venus

QuickCores specializes in FPGA-embeddable microcontroller cores such
as 68HC05, 16C5x and proprietary 9-bit RISC.  At the moment, only
synthesized in Actel ProASIC+ and QuickLogic.  Includes JTAG real-time
debug module.

You can download ref. designs (STAPL format) for free at
www.quickcores.com.

You can also take a look at opencores.org website:  www.opencores.org

Jerry

Article: 46546
Subject: Re: Hardware Code Morphing?
From: "David Brown" <david@no.westcontrol.spam.com>
Date: Tue, 3 Sep 2002 08:53:57 +0200
Links: << >>  << T >>  << A >>

"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
news:al0fks$in9$2@agate.berkeley.edu...
> In article <al0f65$evv$1@vkhdsu24.hda.hydro.com>,
> Terje Mathisen  <terje.mathisen@hda.hydro.com> wrote:
> >The pure sw emulation approach was tried with DECs FX-32 (sp?), it
> >worked OK for applications but could never handle an OS.
>
> Well, it handled MOST of the OS, IIRC.  I seem to recall the portable
> NT relying very heavily on a 486 emulator.
> --

And the first versions of MacOS for the early PowerMacs emulated most of the
68k OS Code on the PPC.




Article: 46547
Subject: Question about IOB, BUFG, IBUF and IBUG.
From: "BROTO Laurent" <lbroto@free.fr>
Date: Tue, 3 Sep 2002 10:01:19 +0200
Links: << >>  << T >>  << A >>
Hi all !

I would like to know what's utility of these differents buffers and
differences between them.

I've undertsood this:
 - when I want to input CLK signal in my fpga, I must to use IBUFG, but why
?
 - when I want to map an output of a DLL on other process or on other DLL, I
must to use BUFG. But why ?

Thanks a lot,

--

Laurent



Article: 46548
Subject: Re: In 2 clk domains. How to xfer data from 1 bus to the another ?
From: dorron@hotmail.com (Paul)
Date: 3 Sep 2002 01:03:29 -0700
Links: << >>  << T >>  << A >>
Hello,

> I have two data buses running at two different but constant clock...

Have a look at http://www.sunburst-design.com/papers/

There are some papers regarding this topic, namely:
 - Synthesis and Scripting Techniques for Designing Multi-Asynchronous
Clock Designs

And if you finally need a FIFO to do it:

 - Simulation and Synthesis Techniques for Asynchronous FIFO Design 
 - Simulation and Synthesis Techniques for Asynchronous FIFO Design
with Asynchronous Pointer Comparisons.

The other papers in this website are very recommendable as well.

Regards,
Paul.

Article: 46549
Subject: Re: IT consultant vs Engineer
From: "Hans Summers" <Hans.Summers@Tudor.Com>
Date: Tue, 3 Sep 2002 09:04:56 +0100
Links: << >>  << T >>  << A >>

IT often pays better which isn't offensive ;-)


--
------------------
Hans Summers
http://www.HansSummers.Com



"Duy K Do" <duy_do@angelfire.com> wrote in message
news:3ecf0f2c.0209020735.32af1a34@posting.google.com...
> Do you get offended if someone label you as IT consultant?
> Sadly a lot of talented engineering graduates ended up in IT department.
>
> Cheers!
>
> Duy K Do





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