Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
> 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, JonBArticle: 66576
Hi, Does anyone know about Altera VQM to EDIF converter? I appreciate for any ideas... Cheers KrzysiekArticle: 66577
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 ? ReneArticle: 66578
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
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> > 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-4800777Article: 66582
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
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
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ürgenArticle: 66585
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 8pmArticle: 66586
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 controllerArticle: 66587
"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
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
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: 66590The 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
? 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
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
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
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). -jgArticle: 66595
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
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
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, TonyArticle: 66598
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..) ? -jgArticle: 66599
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:
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