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 66575

Article: 66575
Subject: Re: Spartan 3 - avaliable in small quantities?
From: jon@beniston.com (Jon Beniston)
Date: 23 Feb 2004 03:32:41 -0800
Links: << >>  << T >>  << A >>
> I am even tempted to max the datapath to 64b as it only
> adds 3-4 pipestages and not much to the control.

Sure, but the more pipeline stages you add, the longer the latency is
for each instruction. How many cycles latency will there be for a
single add instruction? Do you intend to make sure that the number of
threads is equal to this latency, so that the latency as perceived the
thread executing the instruction is 0?

What's your cache / memory architecture? Handling lots of threads
could be tricky.

Cheers,
JonB

Article: 66576
Subject: VQM to EDIF
From: "krzychosz" <krzychosz@interia.pl>
Date: Mon, 23 Feb 2004 12:53:39 +0100
Links: << >>  << T >>  << A >>
Hi,

Does anyone know about Altera VQM to EDIF converter? I appreciate for any
ideas...

Cheers
Krzysiek



Article: 66577
Subject: Re: erasing a MAX device
From: Rene Tschaggelar <none@none.net>
Date: Mon, 23 Feb 2004 14:03:39 +0100
Links: << >>  << T >>  << A >>
Rene Tschaggelar wrote:
> A feature forgotten by the developpers of the MaxPlus2
> software is the ability to just erase a (MAX) device.
> Having some troubles with some other hardware which
> should have defined output pins going to defined input pins
> on a MAX3128 leads to this device not being initialized.
> This makes the MAX3128 have open inputs drawing too much power.
> 
> There wasn't any problem before the MAX3128 was programmed,
> and I therefore wish to erase the MAX3128. Just erase.

BTW. I found the appnote telling about using the JAM player.
   jam -dDO_ERASE ...

But why not just have a button in the usual software ?

Rene

Article: 66578
(removed)


Article: 66579
Subject: Xilinx Microblaze and C++
From: Anders Hellerup Madsen <anders@hellerup-madsen.dk>
Date: Mon, 23 Feb 2004 15:19:03 +0100
Links: << >>  << T >>  << A >>
Hi,

According to the Xilinx EDK documentation, it should be possible to use
C++ code with the Microblaze CPU, but unfortunately the documentation
doesn't say anything about how one would do this. The Xilinx web page
and support forums doesn't have any information about C++ either, so I
was wondering if anyone have had any succes at all with C++ and
Microblaze systems?

My main problems seems to be with the linker (mb-ld). I can't link
anything against the Standard Template Libary. The sourcecode seems to
compile nicely enough, but when the linker tries to link the object
files, it's seems to encounter an unexpected '(' in it's own default
linker script. What's up with that?

I would really apreciate any input from everyone, and I appologise for
my horrible english. Hope you can help,

-- Anders


Article: 66580
Subject: Re: altera, xilinx susceptible to power transients?
From: Ray Andraka <ray@andraka.com>
Date: Mon, 23 Feb 2004 10:13:53 -0500
Links: << >>  << T >>  << A >>
5-10ns is a very narrow spike on the power, which should be caught mostly by your power supply bypassing.
It is quite possible you have insufficient power supply bypassing on your board which is causing upsets or
false clock transitions due to the narrow transients.  Try it with much slower changes in the supply
voltage, you'll see then that the chip continues to operate (although it slows down) as power is reduced
until the reconfiguration reset trips.


Naveed wrote:

> "Jeff" <koebrich@sbcglobal.net> wrote in message news:<pijZb.11786$PY.278@newssvr26.news.prodigy.com>...
> > Just wondering...how susceptible are these RAM based FPGA devices to power
> > supply transients, brownouts, etc?  I am looking on Altera's website and
> > have not found much yet.
> >
> > Thanks,
> >
> > Jeff
>
> I have been using 1.5V cyclone.  Cyclone will reset some of its FF for
> a very fast transient on 1.5V rails.  I am taling about voltage
> dipping well below 1V for more than 5-10nsec multiple times.  I have
> never seen it going into the reconfiguration.
>
> If transient is the problem, avoid using low voltage ICs, go for 2.5V
> or even 3.3V cores.
>
> Naveed

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 66581
Subject: Re: Spartan 3 - avaliable in small quantities?
From: johnjakson@yahoo.com (john jakson)
Date: 23 Feb 2004 07:29:30 -0800
Links: << >>  << T >>  << A >>
> > This is really the same deal with the fastest VLSI cpus that are
> > limited to 10 levels of low fanout gate level logic. Seymour was doing
> > this in ECL 40yrs ago. A LUT counts as 3 levels of gate logic so close
> > enough 10gates.
> > 
> > I will report on the work as it gets closer to live results. 
> 
>   Sounds to me like something you could negotiate
> a job at Xilinx doing :)
> 
>   Their marketing dept would just LOVE to boast about 300+ MHz
> CPU cores, even if that is 'very peaky'. (after all, so are the
> alternatives)
> 
>   Key question is what code size is this working from ?
> 
> -jg

I am sure anyone would love to get a cpu at 300MHz in FPGA but the
arch will be on my terms. The code base is remarkably small v previous
projects I have worked on, the Verilog is <4K IIRC sofar. It will get
bigger for control logic. 1st pass will defer some opcode complexity
to xops as TI9900 once called them ie low overhead low address
subroutines. That will reduce performance of OS message passing
scheduling specific code by 4x or so but its easier to write asm than
design HW. Later FPGA space permitting most of that will get hardened.

Note there is almost no HW needed for hazard detection, no bra
prediction, no pipeline flushing. Just like a DSP really. Other than
that the cpu looks more like 4 78MHz classic Ld St Risc cpus
timesharing the HW (and the cache unfortunately). Actually the
performance on paper should compare well to x86 at 1.5 the clk ie
500MHz x86 but the cache size is a real limit here. I still have to
design cache & TLB HW. Associative HW really costs.

Note that all ccbranches take 0 cycles as they group onto non bra
opcodes. So it may well run smaller loops at effective 400MHz if every
4th op is a bra. Its also a joy to count cycles based on bandwidth the
opcode actually uses, so ccbra really uses 1/8 or 1/4 cycles but from
slack time. And add a<-b+c would actually use 9/8 since the opcode
fetch is another 1/8 from slack time. But a cmp a,b would be 5/8 since
the unused write back gives back 4/8 cycles. Ofcourse the ops really
run in integer cycles, but there are queues to be filled and that uses
slack cache memory ports. The actual non Transputer ISA is actually
quite soft, I can mess with opcode encodings at will since as we all
know, cpus only do movs these days (yeh right).

The arch should port to any FPGA that supports true dual port
2WW/2RR/2RW BlockRams, not really using any other special features.
SRL16 nice if available. This also means it can be ASICed where I
would expect it to run atleast 3x faster as long as the libs include
prebuilt DP Ram as that is always the 1st limit. Other adder width
limits can be worked around. Some time I will get around to trying
free Quartus but I wish they would drop the IP node nonsense.

I am really pushing to get the Transputer arch back in front since
that allows many cpus to work in harmony with the message passing
scheme. It worked well before but Inmos folded up for bad engineering
& business reasons not because the basic premise was unsound. At one
time before 486 came along it was the dominant 32b arch esp in Europe
and very popular with HW embedded & extreme computing types. Occam was
a killer though, most SW types didn't get it although in hindsight I
see it now as a Forthy/Lispy HDL language.

I address that issue by suggesting it be programmed in V++ a language
which just combines std C with Verilog event driven language. It also
includes the Occam primitives Par, Alt, Seq, and !? operators to round
out but using C syntax. HandelC does the same thing and is a SW & HW
language too. I am about half way done on that using lcc as the base
technology. Have to get back to tree generation and code emit. Std lcc
can't just be hacked the way Jan did on XSOC because of the need to
include the Par support. The runtime is really a tiny OS with
scheduler, basic memory management in SW etc. The compiler is actually
90% of the project effort and the HW is almost the easy part,
certainly the fun part. I would like to transfer the compiler workload
pronto but few compiler writers know about Verilog internals etc.

The big kicker here as I keep saying is that end user code can be
written in any of the 3 styles, maybe start in C and rewrite parts in
Occam style message passing to get more parallelism. For real speed
ups rerwite in HDL style and voila the SW can be synthed with any free
FPGA synth tool into something like a coprocessor. Fits in very well
the good article the Altera guy linked here a few days ago on another
thread.

Better get back to work

johnjakson_usa_com

508-4800777

Article: 66582
Subject: Free PCI-bridge in VHDL for Spartan-IIE
From: "Torsten Lauter" <tlau@infotech.tu-chemnitz.de>
Date: Mon, 23 Feb 2004 16:38:17 +0100
Links: << >>  << T >>  << A >>
Free PCI-bridge in VHDL for Spartan-IIE

Somebody knows the implementation of
http://www.infotech.tu-chemnitz.de/~tlau/pci_bridge

Regards.
__________________________________________________________________ Torsten
Lauter ICQ#: 14492119 Current ICQ status: + More ways to contact me
__________________________________________________________________



Article: 66583
Subject: Re: Can FPGA bootstrap itself?
From: Marius Vollmer <marius.vollmer@uni-dortmund.de>
Date: Mon, 23 Feb 2004 16:49:48 +0100
Links: << >>  << T >>  << A >>
hmurray@suespammers.org (Hal Murray) writes:

> Are you interseted in minimizing cost, board space, or
> inelegance?

Mostly inelegance.  I don't want to design a real product (right now),
I'm asking just to improve my understanding.  (So that I can
meaningfully bitch about existing boards :-)

> Various one chip micros are now available in tiny packages.  That would
> be my starting point. The FTDI chips look good.

Yes, the parallel FTDI chip with its bit-bang mode is what I like
most, right now.

Article: 66584
Subject: Usage of Xilinx Library elements in ModelSim simulation
From: foag@iti.uni-luebeck.de (J?rgen)
Date: 23 Feb 2004 08:40:13 -0800
Links: << >>  << T >>  << A >>
I like to simulate our design by using Xilinx library elements
(RAMB16_s4_s4) with ModelSim SE plus 5.7d (on PC). While using the
downloaded xilinx_lib_4.tcl file I obtain the following error
messages:

# Model Technology ModelSim SE vcom 5.7d Compiler 2003.05 May 10 2003
# -- Loading package standard
# -- Loading package std_logic_1164
# -- Loading package vital_timing
# -- Loading package vital_primitives
# -- Loading package textio
# -- Compiling package vpackage
# -- Compiling package body vpackage
# -- Loading package vpackage
# Model Technology ModelSim SE vcom 5.7d Compiler 2003.05 May 10 2003
# -- Loading package standard
# -- Loading package std_logic_1164
# -- Loading package vital_timing
# -- Compiling package vcomponents
# Model Technology ModelSim SE vcom 5.7d Compiler 2003.05 May 10 2003
# -- Loading package standard
# -- Loading package std_logic_1164
# -- Loading package std_logic_arith
# -- Loading package std_logic_unsigned
# -- Loading package vital_timing
# -- Loading package vital_primitives
# -- Loading package textio
# -- Loading package vpackage
# -- Compiling entity x_and16
# -- Compiling architecture x_and16_v of x_and16
# -- Compiling entity x_and2
# -- Compiling architecture x_and2_v of x_and2
# -- Compiling entity x_and3
# -- Compiling architecture x_and3_v of x_and3
# -- Compiling entity x_and32
# -- Compiling architecture x_and32_v of x_and32
# -- Compiling entity x_and4
# -- Compiling architecture x_and4_v of x_and4
# -- Compiling entity x_and5
# -- Compiling architecture x_and5_v of x_and5
# -- Compiling entity x_and6
# -- Compiling architecture x_and6_v of x_and6
# -- Compiling entity x_and7
# -- Compiling architecture x_and7_v of x_and7
# -- Compiling entity x_and8
# -- Compiling architecture x_and8_v of x_and8
# -- Compiling entity x_and9
# -- Compiling architecture x_and9_v of x_and9
# -- Compiling entity x_bpad
# -- Compiling architecture x_bpad_v of x_bpad
# -- Compiling entity x_buf
# -- Compiling architecture x_buf_v of x_buf
# -- Compiling entity x_buf_pp
# -- Compiling architecture x_buf_pp_v of x_buf_pp
# -- Compiling entity x_bufgmux
# -- Compiling architecture x_bufgmux_v of x_bufgmux
# -- Compiling entity x_bufgmux_1
# -- Compiling architecture x_bufgmux_1_v of x_bufgmux_1
# -- Compiling entity x_ckbuf
# -- Compiling architecture x_ckbuf_v of x_ckbuf
# -- Compiling entity x_clkdll_maximum_period_check
# -- Compiling architecture x_clkdll_maximum_period_check_v of 
x_clkdll_maximum_period_check
# -- Compiling entity x_clkdll
# -- Compiling architecture x_clkdll_v of x_clkdll
# -- Loading entity x_clkdll_maximum_period_check
# -- Compiling entity x_clkdlle_maximum_period_check
# -- Compiling architecture x_clkdlle_maximum_period_check_v of 
x_clkdlle_maximum_period_check
# -- Compiling entity x_clkdlle
# -- Compiling architecture x_clkdlle_v of x_clkdlle
# -- Loading entity x_clkdlle_maximum_period_check
# -- Compiling entity dcm_clock_divide_by_2
# -- Compiling architecture dcm_clock_divide_by_2_v of
dcm_clock_divide_by_2
# -- Compiling entity dcm_maximum_period_check
# -- Compiling architecture dcm_maximum_period_check_v of 
dcm_maximum_period_check
# -- Compiling entity dcm_clock_lost
# -- Compiling architecture dcm_clock_lost_v of dcm_clock_lost
# -- Compiling entity x_dcm
# -- Compiling architecture x_dcm_v of x_dcm
# -- Loading entity dcm_clock_divide_by_2
# -- Loading entity dcm_maximum_period_check
# -- Loading entity dcm_clock_lost
# -- Compiling entity x_fddrcpe
# -- Compiling architecture x_fddrcpe_v of x_fddrcpe
# -- Compiling entity x_fddrrse
# -- Compiling architecture x_fddrrse_v of x_fddrrse
# -- Compiling entity x_ff
# -- Compiling architecture x_ff_v of x_ff
# -- Compiling entity x_ibufds
# -- Compiling architecture x_ibufds_v of x_ibufds
# -- Compiling entity x_inv
# -- Compiling architecture x_inv_v of x_inv
# -- Compiling entity x_ipad
# -- Compiling architecture x_ipad_v of x_ipad
# -- Compiling entity x_keeper
# -- Compiling architecture x_keeper_v of x_keeper
# -- Compiling entity x_latch
# -- Compiling architecture x_latch_v of x_latch
# -- Compiling entity x_latche
# -- Compiling architecture x_latche_v of x_latche
# -- Compiling entity x_lut2
# -- Compiling architecture x_lut2_v of x_lut2
# -- Compiling entity x_lut3
# -- Compiling architecture x_lut3_v of x_lut3
# -- Compiling entity x_lut4
# -- Compiling architecture x_lut4_v of x_lut4
# -- Compiling entity x_lut5
# -- Compiling architecture x_lut5_v of x_lut5
# -- Compiling entity x_lut6
# -- Compiling architecture x_lut6_v of x_lut6
# -- Compiling entity x_lut7
# -- Compiling architecture x_lut7_v of x_lut7
# -- Compiling entity x_lut8
# -- Compiling architecture x_lut8_v of x_lut8
# -- Compiling entity x_mult18x18
# -- Compiling architecture x_mult18x18_v of x_mult18x18
# -- Compiling entity x_mult18x18s
# ** Error: 
C:/Programme/FPGAdv61/Modeltech/xilinx/vhdl/unisim/ramb4_s16_s16/vhdl/src/simpri
ms/simprim_VITAL.vhd(9368): VITAL TISD timing generic must be a scalar
form of
VITAL 
# delay type
# (1076.4 section 4.3.2.1.3.13)
# ** Error: 
C:/Programme/FPGAdv61/Modeltech/xilinx/vhdl/unisim/ramb4_s16_s16/vhdl/src/simpri
ms/simprim_VITAL.vhd(9369): VITAL TISD timing generic must be a scalar
form of
VITAL 
# delay type
# (1076.4 section 4.3.2.1.3.13)
# ** Error: 
C:/Programme/FPGAdv61/Modeltech/xilinx/vhdl/unisim/ramb4_s16_s16/vhdl/src/simpri
ms/simprim_VITAL.vhd(9391): VHDL Compiler exiting

What can I do/where can I obtain already compiled Xilinx library
elements for simulation ?

Jürgen

Article: 66585
Subject: Re: Spartan 3 - avaliable in small quantities?
From: johnjakson@yahoo.com (john jakson)
Date: 23 Feb 2004 08:45:31 -0800
Links: << >>  << T >>  << A >>
jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0402230332.3e1160e@posting.google.com>...
> > I am even tempted to max the datapath to 64b as it only
> > adds 3-4 pipestages and not much to the control.
> 
> Sure, but the more pipeline stages you add, the longer the latency is
> for each instruction. How many cycles latency will there be for a
> single add instruction? Do you intend to make sure that the number of
> threads is equal to this latency, so that the latency as perceived the
> thread executing the instruction is 0?
> 
> What's your cache / memory architecture? Handling lots of threads
> could be tricky.
> 
> Cheers,
> JonB

I just posted a very long reply but the server just xxxxed it so I
will write it again later offline.

Quick answer yes, HT must match 4 or 8 etc. Cache architecture is
currently 1 way set associative, but more Blockrams would allow more
ways. Question of whether the FPGA should hold lots of lite cpus or 1
monster cpu or maybe combinations of both!

Regards

johnjakson_usa_com

508 4800777 EST after 8pm

Article: 66586
Subject: OpenCore.org DDR SDRAM problems
From: "Yttrium" <Yttrium@pandora.be>
Date: Mon, 23 Feb 2004 16:55:23 GMT
Links: << >>  << T >>  << A >>
hey,

i needed a ddr sdram controller for a MT46V16M16 so when i saw the IPCORE on
OpenCores.org i thought why not use it ... so i have build all the necessary
controlling processes and blocks and simulated it and tried it out on a
virtexII FPGA and worked fine, then i connected the DDR controller to it at
i got this HUGE list of warnings about unconnected elements. (i attached it
to this message for the curious one among you) and i was just wondering if
other people already had this problem and maybe solved them... any help is
welcome ...

thanx in advance,

kind regards,

yttrium

P.S. this is just on part of the project: in this part data has to come from
a pc through uart towards RAM and the on VGA/PAL (all the necessary parts
for this part have been done and tested, so only the ram controller fails to
do his job ;-) ...)

P.P.S. just found out that this newsgroup will not accept attachements from
me ;-)

INFO:Xst:1317 - HDL ADVISOR - A dynamic shift register was found for signal
<_n0165<0>> and currently occupies 2 logic cells (1 slices) for the
flip-flop chain and additional logic cells for the multiplexer. Removing the
set/reset logic would take advantage of SRL16 (and derived) primitives and
reduce this to 1 logic cells (1 slices). Evaluate if the set/reset can be
removed for this simple shift register. The majority of simple pipeline
structures do not need to be set/reset operationally.
INFO:Xst:1317 - HDL ADVISOR - A dynamic shift register was found for signal
<_n0165<1>> and currently occupies 2 logic cells (1 slices) for the
flip-flop chain and additional logic cells for the multiplexer. Removing the
set/reset logic would take advantage of SRL16 (and derived) primitives and
reduce this to 1 logic cells (1 slices). Evaluate if the set/reset can be
removed for this simple shift register. The majority of simple pipeline
structures do not need to be set/reset operationally.
INFO:Xst:1317 - HDL ADVISOR - A dynamic shift register was found for signal
<_n0165<2>> and currently occupies 2 logic cells (1 slices) for the
flip-flop chain and additional logic cells for the multiplexer. Removing the
set/reset logic would take advantage of SRL16 (and derived) primitives and
reduce this to 1 logic cells (1 slices). Evaluate if the set/reset can be
removed for this simple shift register. The majority of simple pipeline
structures do not need to be set/reset operationally.
INFO:Xst:1317 - HDL ADVISOR - A dynamic shift register was found for signal
<_n0165<3>> and currently occupies 2 logic cells (1 slices) for the
flip-flop chain and additional logic cells for the multiplexer. Removing the
set/reset logic would take advantage of SRL16 (and derived) primitives and
reduce this to 1 logic cells (1 slices). Evaluate if the set/reset can be
removed for this simple shift register. The majority of simple pipeline
structures do not need to be set/reset operationally.


and



WARNING:Xst:1291 - FF/Latch <shift_q_1_12> is unconnected in block
<ddr_sdr>.
WARNING:Xst:1291 - FF/Latch <shift_q_1_13> is unconnected in block
<ddr_sdr>.
WARNING:Xst:1291 - FF/Latch <shift_q_1_14> is unconnected in block
<ddr_sdr>.
WARNING:Xst:1291 - FF/Latch <shift_q_1_15> is unconnected in block
<ddr_sdr>.


and



WARNING:Xst:1710 - FF/Latch  <ddr_ram_module_row_adr_q_0> (without init
value) is constant in block <picture_vga>.
WARNING:Xst:1710 - FF/Latch  <ddr_ram_module_row_adr_q_1> (without init
value) is constant in block <picture_vga>.


are some of the warnings i get from the controller



Article: 66587
Subject: Re: VQM to EDIF
From: David Rogoff <david@therogoffs.com>
Date: Mon, 23 Feb 2004 09:56:56 -0800
Links: << >>  << T >>  << A >>
"krzychosz" <krzychosz@interia.pl> writes:

> Hi,
>
> Does anyone know about Altera VQM to EDIF converter? I appreciate for any
> ideas...

VQM is just a verilog netlist (with a ton of defparams), so you need
verilog -> edif.  

Article: 66588
Subject: Re: OpenCore.org DDR SDRAM problems
From: PO Laprise <pl_N0SP4M_apri@cim._N0SP4M_mcgill.ca>
Date: Mon, 23 Feb 2004 18:16:34 GMT
Links: << >>  << T >>  << A >>
Yttrium wrote:
> hey,
> 
> i needed a ddr sdram controller for a MT46V16M16 so when i saw the IPCORE on
> OpenCores.org i thought why not use it ... so i have build all the necessary
> controlling processes and blocks and simulated it and tried it out on a
> virtexII FPGA and worked fine, then i connected the DDR controller to it at
> i got this HUGE list of warnings about unconnected elements. (i attached it
> to this message for the curious one among you) and i was just wondering if
> other people already had this problem and maybe solved them... any help is
> welcome ...
> 

Hi Yttrium, I had managed to get that core up and working with ISE5, but 
have been having trouble since migrating to ISE6.  I made some changes 
to my code at around the same time, though, so I'm 99.99% certain it's 
my problem...  One thing I found was that I needed to increase the 
REFRESH_WINDOW constant in ddr_sdr_conf_pkg.vhd to 18 to avoid problems 
with some combinations of write-with-precharge commands interfering with 
the refreshing of the memory.  This is a quick-and-dirty fix, with 
certain costs in terms of performance, but it makes things stable.  See 
below for my comments on your warnings...

<snip>
> INFO:Xst:1317 - HDL ADVISOR - A dynamic shift register was found for signal
> <_n0165<0>> and currently occupies 2 logic cells (1 slices) for the
> flip-flop chain and additional logic cells for the multiplexer. Removing the
> set/reset logic would take advantage of SRL16 (and derived) primitives and
> reduce this to 1 logic cells (1 slices). Evaluate if the set/reset can be
> removed for this simple shift register. The majority of simple pipeline
> structures do not need to be set/reset operationally.
> INFO:Xst:1317 - HDL ADVISOR - A dynamic shift register was found for signal
> <_n0165<1>> and currently occupies 2 logic cells (1 slices) for the
> flip-flop chain and additional logic cells for the multiplexer. Removing the
> set/reset logic would take advantage of SRL16 (and derived) primitives and
> reduce this to 1 logic cells (1 slices). Evaluate if the set/reset can be
> removed for this simple shift register. The majority of simple pipeline
> structures do not need to be set/reset operationally.
> INFO:Xst:1317 - HDL ADVISOR - A dynamic shift register was found for signal
> <_n0165<2>> and currently occupies 2 logic cells (1 slices) for the
> flip-flop chain and additional logic cells for the multiplexer. Removing the
> set/reset logic would take advantage of SRL16 (and derived) primitives and
> reduce this to 1 logic cells (1 slices). Evaluate if the set/reset can be
> removed for this simple shift register. The majority of simple pipeline
> structures do not need to be set/reset operationally.
> INFO:Xst:1317 - HDL ADVISOR - A dynamic shift register was found for signal
> <_n0165<3>> and currently occupies 2 logic cells (1 slices) for the
> flip-flop chain and additional logic cells for the multiplexer. Removing the
> set/reset logic would take advantage of SRL16 (and derived) primitives and
> reduce this to 1 logic cells (1 slices). Evaluate if the set/reset can be
> removed for this simple shift register. The majority of simple pipeline
> structures do not need to be set/reset operationally.
> 

The first group of warnings are just some helpful suggestions by ISE 
telling you that the shift registers could be packed into SRL16 
components instead of using a bunch of flip-flops if you can forego 
using reset pins.

> 
> and
> 
> 
> 
> WARNING:Xst:1291 - FF/Latch <shift_q_1_12> is unconnected in block
> <ddr_sdr>.
> WARNING:Xst:1291 - FF/Latch <shift_q_1_13> is unconnected in block
> <ddr_sdr>.
> WARNING:Xst:1291 - FF/Latch <shift_q_1_14> is unconnected in block
> <ddr_sdr>.
> WARNING:Xst:1291 - FF/Latch <shift_q_1_15> is unconnected in block
> <ddr_sdr>.
> 

If you look at the source code, you'll notice that shift_q is actually a 
2-stage FIFO (data_in->shift_q(0)->shift_q(1)->ddr_data) used to delay 
input data.  The lower bits of shift_q(1) aren't actually used, though 
(ddr_data <= [upper half of shift_q(1)] & [lower half of shift_q(0)]), 
which explains these warnings.

> 
> WARNING:Xst:1710 - FF/Latch  <ddr_ram_module_row_adr_q_0> (without init
> value) is constant in block <picture_vga>.
> WARNING:Xst:1710 - FF/Latch  <ddr_ram_module_row_adr_q_1> (without init
> value) is constant in block <picture_vga>.
> 

I'm guessing that the 2 LSb's of your address are never modified, i.e. 
you increment your address by multiples of 4?

So overall, the warnings you get seem fairly benign (although I can't 
really say for sure for the one about ddr_ram_module_row_adr_q). 
Warnings aren't necessarily bad.  Check each one, and if you know that 
it's not a problem, ignore it, or change the code so that the warning 
doesn't appear (if possible).

-- 
Pierre-Olivier

P.S. Text is always better than attachments in newsgroups.  Cut down 
what you have to the bare essentials and then present it in text form. 
This avoids many problems for many people and increases the chances of 
people responding to your mail.

-- to email me directly, remove all _N0SP4M_ from my address --


Article: 66589
Subject: Re: Spartan 3 - avaliable in small quantities?
From: Ray Andraka <ray@andraka.com>
Date: Mon, 23 Feb 2004 13:18:16 -0500
Links: << >>  << T >>  << A >>
John,

In my experience, the stumbling block for custom CPUs is not so much the hardware as it is the compiler for
it.  I did a small microcontroller for a XC4036E design several years back that ran at 66 Mhz.  It was a
pretty simple machine that was sort of a cross between a PIC and an RCA1802 in that it used a 16 deep
register file like the 1802, and it was a harvard architecture like the PIC.   Like the 1802, the operands
for the ALU were fetched from the register file and results returned to the register file.  The beauty of it
was that for control applications, you often did not even need any memory beyond the register file.  The
processor size was about 80 CLBs (translates to 80 slices in current architectures).   I'm not a compiler
person, so the big difficulty I had with it was the compiler.

I suspect that the difficulty for just about any home grown processor is going to be the tools to compile the
code for it, although folks who are more saavy than I on the software side might argue that the high speed
hardware design is the hard part.


john jakson wrote:

> jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0402230332.3e1160e@posting.google.com>...
> > > I am even tempted to max the datapath to 64b as it only
> > > adds 3-4 pipestages and not much to the control.
> >
> > Sure, but the more pipeline stages you add, the longer the latency is
> > for each instruction. How many cycles latency will there be for a
> > single add instruction? Do you intend to make sure that the number of
> > threads is equal to this latency, so that the latency as perceived the
> > thread executing the instruction is 0?
> >
> > What's your cache / memory architecture? Handling lots of threads
> > could be tricky.
> >
> > Cheers,
> > JonB
>
> I just posted a very long reply but the server just xxxxed it so I
> will write it again later offline.
>
> Quick answer yes, HT must match 4 or 8 etc. Cache architecture is
> currently 1 way set associative, but more Blockrams would allow more
> ways. Question of whether the FPGA should hold lots of lite cpus or 1
> monster cpu or maybe combinations of both!
>
> Regards
>
> johnjakson_usa_com
>
> 508 4800777 EST after 8pm

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 66590
Subject: Re: FPGA vendors and their patents
From: "Steve Casselman" <sc.nospam@vcc.com>
Date: Mon, 23 Feb 2004 19:24:23 GMT
Links: << >>  << T >>  << A >>
The earliest Xilinx patent is 4,870,302 Feb 19 1988. So it expires next year

Steve

"Paul Franklin" <paulfr@dacafe.com> wrote in message
news:518ec9d9.0402180243.2590fca0@posting.google.com...
> I heard something about some major FPGA patents due to expire soon. I
> think these are owned by Xilinx and/or Altera.
>
> I would be interested if anybody can clarify what exactly these
> patents are, and if anyone has an opinion on if their expiry could
> potentially enable market entry by new entrants to the FPGA arena or
> new product families by the exisiting FPGA vendors.
>
> Regards,
> Paul.
>



Article: 66591
Subject: Re: FPGA vendors and their patents
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 23 Feb 2004 11:37:02 -0800
Links: << >>  << T >>  << A >>
?

Of course, there are more patents that Xilinx has filed since then.

By the way, others have entered the FPGA business (an left it -- 
unsuccessfully) and did not infringe on any patents, so it can be done.

Why did they not succeed?  Did it have to do with patents?

Nope.

Austin

Steve Casselman wrote:
> The earliest Xilinx patent is 4,870,302 Feb 19 1988. So it expires next year
> 
> Steve
> 
> "Paul Franklin" <paulfr@dacafe.com> wrote in message
> news:518ec9d9.0402180243.2590fca0@posting.google.com...
> 
>>I heard something about some major FPGA patents due to expire soon. I
>>think these are owned by Xilinx and/or Altera.
>>
>>I would be interested if anybody can clarify what exactly these
>>patents are, and if anyone has an opinion on if their expiry could
>>potentially enable market entry by new entrants to the FPGA arena or
>>new product families by the exisiting FPGA vendors.
>>
>>Regards,
>>Paul.
>>
> 
> 
> 

Article: 66592
Subject: [Fwd: Solution Update [WAS: Re: EDK6.1 vs. EDK3.2 clarification]]
From: Jon Masters <jonathan@jonmasters.org>
Date: Mon, 23 Feb 2004 20:01:46 +0000
Links: << >>  << T >>  << A >>
X-Complaints-To: abuse@supernews.com
Lines: 108
Xref: newsmst01.news.prodigy.com comp.arch.fpga:68797




Hi there,

This never turned up due to a connection limit with my ISP.

Flush those damn caches!

Jon.






Hi there,

I thought it prudent to update anyone who later reads this thread as to
the cause and outcome of this issue which was ongoing for a while.

It turns out that I had not correctly initialised the cache controller
in my firmware and today was able to prove that this had worked on the
old hardware generated with EDK3.2 however this was not the case with
EDK6.1 for whatever reason. It was not the Linux kernel at fault.

Perhaps I could moan about the various documentation and other issues
but it comes down to a bit of code which got changed at some point,
continued to work ok but later caused a hiccup with new hardware as the
data cache not being properly flushed on startup resulted in fun.

Bottom line is I now once more have a fully working Insight Memec V2P
port with EDK6.1 hardware and our custom modules are now in again.

I think someone else had similar symptoms...

Cheers,

Jon.

P.S. Thanks for reading.

P.P.S. I am going to FOSDEM in the morning if anyone cares.





Article: 66593
Subject: Why does Xilinx keep saying LVPECL_2.5 and _3.3V are identical?
From: qlyus@yahoo.com (qlyus)
Date: 23 Feb 2004 12:02:52 -0800
Links: << >>  << T >>  << A >>
Xilinx keeps saying LVPECL_2.5 and _3.3V inputs are identical. 
Obviously they are NOT.  Virtex-II Pro lists only LVPECL_2.5. 
LVPECL_3.3 can be found in Virtex-II.  Xilinx are saying THEY ARE
IDENTICAL all the time, including in a reply when I asked
specifically.  I had to copy/paste the numbers in the data sheets and
pointed out Vih=1.49-2.72 in LVPECL_3.3 is NOT identical to
Vih=0.8-1.2 in LVPECL_2.5, Vil ....  When admitted those numbers were
not identical, Xilinx simply just said "go ahead do simulation" and
closed the case.

Now there are two answer records talking about "...because the input
specifications for LVDS_25/33 and LVPECL_25/33 are identical."

Here is the quote from Answer Record # 18095:

"LVDS and LVPECL specifications are available in the "DC and Switching
Characteristics" section of the Spartan-3 data sheet:
http://direct.xilinx.com/bvdocs/publications/ds099-3.pdf"

But Spartan-3 data sheet does not have LVPECL listed in
characteristics section at all.

Can somebody here help to understand all of these things?  I am really
confused.

-qlyus 

Answer Record # 18095 Spartan-3 - Can I interface a 3.3 volt LVDS or
LVPECL device to a Spartan-3?
Spartan-3 supports only LVDS_25 and LVPECL_25. Can I interface a 3.3
volt LVDS or LVPECL device to a Spartan-3?...
(18130 bytes)
 
Answer Record # 16830 Virtex-II Pro - Can I put LVDS or LVPECL I/O in
the 3.3V bank?
Virtex-II offers two options for powering LVDS drivers: 2.5V and 3.3V
(both have identical electrical characteristics). Is this possible
with Virtex-II Pro? Can I put LVPECL I/O in the 3.3V bank?...
(25146 bytes)

Article: 66594
Subject: Re: Spartan 3 - avaliable in small quantities?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 24 Feb 2004 10:02:15 +1300
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> John,
> 
> In my experience, the stumbling block for custom CPUs is not so much the hardware as it is the compiler for
> it.  I did a small microcontroller for a XC4036E design several years back that ran at 66 Mhz.  It was a
> pretty simple machine that was sort of a cross between a PIC and an RCA1802 in that it used a 16 deep
> register file like the 1802, and it was a harvard architecture like the PIC.   Like the 1802, the operands
> for the ALU were fetched from the register file and results returned to the register file.  The beauty of it
> was that for control applications, you often did not even need any memory beyond the register file.  The
> processor size was about 80 CLBs (translates to 80 slices in current architectures).   I'm not a compiler
> person, so the big difficulty I had with it was the compiler.
> 
> I suspect that the difficulty for just about any home grown processor is going to be the tools to compile the
> code for it, although folks who are more saavy than I on the software side might argue that the high speed
> hardware design is the hard part.

  This is right, and John admits this in another reply.
You should also add DEBUG support, as that's more important as the CPU 
targets bigger applications.
  Once you have a compiler, users will want to do more and more, and 
then debug becomes very important.

  It depends a lot on the target use.
Something that runs from a Block RAM inside the FPGA, can be very 
small/very fast, but is probably best coded in some form of Assembler.
  Best example of 'Advanced Assembler Art' is Randy Hyde's HLA (High 
level Assembler) but that currently targets only x86
- tho I'm sure that's not hard to fix :)
  This HLA allows IF..THEN..ELSIF etc, and handles the labels needed,
as well as giving local scope (so is a big step-up from vanilla ASM).

-jg



Article: 66595
Subject: Re: EDK 6.1 vs 3.2 and OPB Bus resets
From: Carlos Villalpando <newsgrp@brain.jpl.nasa.gov>
Date: Mon, 23 Feb 2004 13:05:41 -0800
Links: << >>  << T >>  << A >>
Sean Durkin wrote:
> In my case the solution was to explicitely set the 
> C_MIR_BASEADDR and C_MIR_HIGHADDR parameters for my IP-core, after that 
> it all worked fine. The strange thing is that I need to set this even if 
> I turn off the MIR completely.

That was it.  Odd for me too since I'm not using the MIR either.  So I 
set it off to la-la land where the PLB->OPB bridge didn't translate.

--Carlos V.

Article: 66596
Subject: Re: Why does Xilinx keep saying LVPECL_2.5 and _3.3V are identical?
From: "John_H" <johnhandwork@mail.com>
Date: Mon, 23 Feb 2004 21:14:46 GMT
Links: << >>  << T >>  << A >>
qlyus,

The Virtex-II DC & Switching Characteristics data sheet mentions that "These
values are valid when driving a 100 ? differential load only" suggesting
that the LVPECL standard is supported for DIFFERENTIAL SIGNALS not the
single ended you appear to be going toward.  For a differential signal to
work, both inputs have to be within the receiver's common mode range *and*
have a differential swing at least as high as the receiver's minimum.

If you checked into the Virtex-II user's guide as the Virtex-II data sheet
suggested, the write-up on Using LVPECL I/O in chapter 3 you'll see the
implementation is entirely differential.

If you want to use single-ended LVPECL, you may need to do things a bit
differently and derive your own numbers.  Two approaches that *may* work for
a pseudo-LVPECL would be to tie a center-crossing reference to *each*
differential input pair or define the inputs as a reference-based single
input standard with a slighlty different (but very close) center threshold
reference.



"qlyus" <qlyus@yahoo.com> wrote in message
news:da71446f.0402231202.2f8e93ad@posting.google.com...
> Xilinx keeps saying LVPECL_2.5 and _3.3V inputs are identical.
> Obviously they are NOT.  Virtex-II Pro lists only LVPECL_2.5.
> LVPECL_3.3 can be found in Virtex-II.  Xilinx are saying THEY ARE
> IDENTICAL all the time, including in a reply when I asked
> specifically.  I had to copy/paste the numbers in the data sheets and
> pointed out Vih=1.49-2.72 in LVPECL_3.3 is NOT identical to
> Vih=0.8-1.2 in LVPECL_2.5, Vil ....  When admitted those numbers were
> not identical, Xilinx simply just said "go ahead do simulation" and
> closed the case.
>
> Now there are two answer records talking about "...because the input
> specifications for LVDS_25/33 and LVPECL_25/33 are identical."
>
> Here is the quote from Answer Record # 18095:
>
> "LVDS and LVPECL specifications are available in the "DC and Switching
> Characteristics" section of the Spartan-3 data sheet:
> http://direct.xilinx.com/bvdocs/publications/ds099-3.pdf"
>
> But Spartan-3 data sheet does not have LVPECL listed in
> characteristics section at all.
>
> Can somebody here help to understand all of these things?  I am really
> confused.
>
> -qlyus
>
> Answer Record # 18095 Spartan-3 - Can I interface a 3.3 volt LVDS or
> LVPECL device to a Spartan-3?
> Spartan-3 supports only LVDS_25 and LVPECL_25. Can I interface a 3.3
> volt LVDS or LVPECL device to a Spartan-3?...
> (18130 bytes)
>
> Answer Record # 16830 Virtex-II Pro - Can I put LVDS or LVPECL I/O in
> the 3.3V bank?
> Virtex-II offers two options for powering LVDS drivers: 2.5V and 3.3V
> (both have identical electrical characteristics). Is this possible
> with Virtex-II Pro? Can I put LVPECL I/O in the 3.3V bank?...
> (25146 bytes)



Article: 66597
Subject: ML300 EDK 6.1 Simulations
From: Tony <nospam@email.com>
Date: Mon, 23 Feb 2004 22:49:12 GMT
Links: << >>  << T >>  << A >>
Hello,

I am following the new (Jan 12 '04)  ML300 EDK user guide to build,
simulate, and run a reference design from the EDK
(http://www.xilinx.com/products/boards/ml300/docs/ml300_ref_des_ug.pdf).

I have no problem building and running the reference design
(system_hello_uart) on the ML300, but simulation will not work.  I
have tried ModelSim SE 5.7 and 5.8, and both generate the same fault
on the same problem.  

Setup: ISE 6.1.03, EDK 6.1.02, ModelSim SE 5.8 and 5.7, with/without
CoreConnect installed
EDK Simulation Settings: 
HDL=VHDL
EDK Library=C:\EDK\mti_se\edklib
Xilinx Library=C:\EDK\mti_se
Simulation Model: (Same error with both Behavioral and Structural)
(all libs compiled without problems, modelsim.ini correctly setup)

Both behavioral and structural generate the following error during
loading, after a bunch of models are compiled into modelsim.  ( after
executing do ../../data/testbench.do):  

(Without CoreConnect installed)
# Loading work.testbench
# Loading work.uart_rcvr
# Loading work.mt46v32m8
# Loading work.pci_targ32
# Loading work.AT24CXXX
# Loading work.plb_monitor3x
# ** Warning: (vsim-3009) [TSCALE] - Module 'plb_monitor3x' does not
have a `timescale directive in effect, but previous modules do.
#         Region: /testbench/plb_monitor
# Loading work.opb_monitor
# ** Warning: (vsim-3009) [TSCALE] - Module 'opb_monitor' does not
have a `timescale directive in effect, but previous modules do.
#         Region: /testbench/opb_mon
# Loading work.dcr_monitor
# ** Warning: (vsim-3009) [TSCALE] - Module 'dcr_monitor' does not
have a `timescale directive in effect, but previous modules do.
#         Region: /testbench/dcr_monitor1
# ** Error: (vsim-3170) Could not find 'work.glbl'.
# Error loading design
# Error: Error loading design 
#        Pausing macro execution 
# MACRO ./../../data/testbench.do PAUSED at line 92

(With CoreConnect installed)
# Loading work.testbench
# Loading work.uart_rcvr
# Loading work.mt46v32m8
# Loading work.pci_targ32
# Loading work.AT24CXXX
# Loading work.plb_monitor3x
# Loading work.plb_monitor_comp3x
# Loading work.opb_monitor
# Loading work.opb_monitor_comp
# Loading work.dcr_monitor
# Loading work.dcr_monitor_comp
# ** Error: (vsim-3170) Could not find 'work.glbl'.
# Error loading design
# Error: Error loading design 
#        Pausing macro execution 
# MACRO ./../../data/testbench.do PAUSED at line 92

Again, this error occurs using modelsim 5.8, 5.7, ML300 EDK Ref design
1 or 2, with or without CoreConnect, and under Behavioral or
Structural simulation.

Is there any way to get this to work?   I have been over this many
times, but always with the same results.  



On another note, when structural model is used, clocks_0_wrapper.vhd
in projects\ml300_edk2\simulation\structural complains about three
cases that are type integer but should be type real  (the two cases
where the period is set to 10 instead of 10.0, and the one case where
the 30 should be 30.0).

# -- Loading package standard
# -- Loading package std_logic_1164
# -- Loading package vital_timing
# -- Loading package vcomponents
# -- Compiling entity clocks_0_wrapper
# -- Compiling architecture structure of clocks_0_wrapper
# -- Loading entity bufg
# -- Loading entity fdp
# -- Loading package std_logic_arith
# -- Loading package std_logic_unsigned
# -- Loading package textio
# -- Loading package vital_primitives
# -- Loading package vpkg
# -- Loading entity srl16
# -- Loading entity ibufg
# -- Loading entity vcc
# -- Loading entity gnd
# -- Loading entity lut1
# -- Loading entity lut2_l
# -- Loading entity lut3
# ** Error: clocks_0_wrapper.vhd(223): Type conflict in integer
literal. Type real versus integer.
# -- Loading entity dcm
# ** Error: clocks_0_wrapper.vhd(258): Type conflict in integer
literal. Type real versus integer.
# ** Error: clocks_0_wrapper.vhd(292): Type conflict in integer
literal. Type real versus integer.
# ** Error: clocks_0_wrapper.vhd(347): VHDL Compiler exiting
# ERROR: C:/Modeltech/win32/vcom failed.
# Error in macro ./system.do line 9
# C:/Modeltech/win32/vcom failed.
#     while executing
# "vcom -93 -work work clocks_0_wrapper.vhd
# "

(the fix for these three errors is to append a "'.0" to each integer,
happens on structural and not behavioral simulations).  Both the old
ML300 EDK Ref #1, and the new Reference packet complain about
integer->real problems on this clocks_0_wrapper.

Thanks,
Tony


Article: 66598
Subject: Re: Dual-stack (Forth) processors
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 24 Feb 2004 12:31:53 +1300
Links: << >>  << T >>  << A >>
Martin Schoeberl wrote:
>>Is there a community that is actively involved in discussing and/or
>>developing FPGA-based Forth chips, or more generally, stack
>>machines?
>>
> 
> 
> Tha Java Virtual Machine is stack based. There are some projects to
> build a 'real' Java machine. You can find more information about a
> solution in an FPGA (with VHDL source) at: http://www.jopdesign.com/
> 
> It is sucessfully implemented in Altera ACEX 1K50, Cyclone (EP1C6) and
> Xilinx Spartan2.
> 
> Martin

Does anyone know of efforts on a FPGA design for .NET bytecodes ?
Any numbers on how much resource it would need, and how that might
compare with a Java machine (or Forth one, for that matter..) ?

-jg


Article: 66599
Subject: Re: Spartan 3 - avaliable in small quantities?
From: johnjakson@yahoo.com (john jakson)
Date: 23 Feb 2004 15:48:34 -0800
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote in message news:<403A43E8.6338D0C1@andraka.com>...
> John,
> 
> In my experience, the stumbling block for custom CPUs is not so much the hardware as it is the compiler for
> it.  I did a small microcontroller for a XC4036E design several years back that ran at 66 Mhz.  It was a
> pretty simple machine that was sort of a cross between a PIC and an RCA1802 in that it used a 16 deep
> register file like the 1802, and it was a harvard architecture like the PIC.   Like the 1802, the operands
> for the ALU were fetched from the register file and results returned to the register file.  The beauty of it
> was that for control applications, you often did not even need any memory beyond the register file.  The
> processor size was about 80 CLBs (translates to 80 slices in current architectures).   I'm not a compiler
> person, so the big difficulty I had with it was the compiler.
> 
> I suspect that the difficulty for just about any home grown processor is going to be the tools to compile the
> code for it, although folks who are more saavy than I on the software side might argue that the high speed
> hardware design is the hard part.
> 
> 

Hi Ray

Half agreed, as Jan has shown any std risc cpu project can grab lcc to
do the task quite quickly by messing with the emit tables. If this
were just another std risc project I'd probably do same, but then it
wouldn't be anywhere near 300MHz either, more like MicroBlaze.

Only hyperthreading allows max speed, but if the processes don't
communicate with each other then lcc could still be used as is and
ignore the HT stuff.

Some of my background is in compilers and other tools but I never
worked for anybody doing that. The lcc compiler (Hanson & Fraser) is
possibly the best documented C compiler writing text book around and
highly recomended as it explains thoroughly just how horrible C really
is where most C books gloss over it's complexity. The complexity for
me comes because I am combining essentially 3 langs together and
putting in a mini OS runtime. The Transputer did it before but chose
an unfriendly syntax and supported C only as an afterthought.

I will probably get through it ok but I would love to pass that part
on but then that person would be knee deep in it instead.

The HW part is more fun though. The 1802 takes me back, not bad in a
twisted sort of way, it certainly used very little logic, I had it
under a scope at Inmos.

Regards

johnjakson_usa_com



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