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 146900

Article: 146900
Subject: Multiple Interrupts Handling
From: Usama <usama817@gmail.com>
Date: Wed, 31 Mar 2010 22:49:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am implementing BMD design as explained in xapp1052(v2.5). Have
implemented the design on Avnet V5LXT/SXT PCIe Development Board using
the PCIe. Have generated the Endpoint Block plus for PCIe 1.9 using
ISE 10.1. I have been successful in running the BMD design with both
the legacy interrupts and Message signal interrupts using single
vector.

The application which I am working on generates multiple interrupts in
the RTL to the host application. So far I have assigned only one
vector to the all the interrupts in the RTL design due to which after
receiving the interrupt at the application end I have to go and check
a register to see which interrupt has occurred. I don=92t want my
application to go and read the register rather it should know which
interrupt has occurred. Now as per the understanding developed through
the document of PCIe endpoint, there are interrupts vectors that need
to be generated at the time of PCIe core generation in order to assign
each interrupt a different vector. The questions I need to ask are as
follow:

=95	How to link the multiple interrupts in the RTL with the multiple
vectors of the MSI?

=95	Are there any changes need to be made in the RTL design?

=95	Is there any reference material that could help me doing this ?

Article: 146901
Subject: Re: FMC Boards ?
From: luudee <rudolf.usselmann@gmail.com>
Date: Wed, 31 Mar 2010 23:04:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 12:04=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Mar 31, 1:51=A0am, luudee <rudolf.usselm...@gmail.com> wrote:
>
> > Does anybody else, besides xilinx, make FMC boards for ml605 & sp605 ?
>
> > HW-FMC-XM105-G =A0FMC XM105 DEBUG CARD
> > HW-FMC-XM104-G =A0FMC CONNECTIVITY MEZZANINE CARD
>
> > Buying Xilinx products now means going through Avnet, which is a
> > nightmare and HUGE lead times ...
>
> > Thanks,
> > rudi
>
> While the XM104 is listed with a 8 week lead time on the Avnet site, I
> know that we have these available in inventory and they will ship
> promptly after the order is placed. =A0The XM105 is listed with a 2 week
> lead time.
>
> There are a number of other companies releasing FMC cards, just be
> sure that the cards support a VADJ of 2.5V and there shouldn't be a
> problem.
>
> 4DSP recently announced a FMC familyhttp://www.przoom.com/news/66794/
>
> Curtiss-Wright also has a number of boards.http://www.cwcembedded.com/0/6=
2/651.html
>
> And Xilinx has a number of other boards in pipeline to be released
> next quarter.http://www.xilinx.com/fmc
>
> Ed McGettigan
> --
> Xilinx Inc.


Thanks Ed !

I was hoping to find an alternative distributor for those boards,
but I guess I have to deal with Avnet :(

Thanks,
rudi


Article: 146902
Subject: Re: Spartan 3E: MAX_STEPS as a function of CLKIN frequency
From: austin <austin@xilinx.com>
Date: Thu, 1 Apr 2010 07:49:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
John,

3E was its own animal, with a completely different and unique DCM
design, unlike all of the others.  I immediately posted that the 256
steps was a mistake in my original post.

3E DCM had some real advantages, but we went back to the "old" DCM
design.

The experience gained in the design of PLLs for the MGTs, led to some
very intense 'digitally calibrated PLL' to the point where in V6, they
are not called DCM nor PLL...as they are not really either (MMCM).

Austin

Article: 146903
Subject: Re: Spartan 6 PLL - Why such a strict input jitter requirement?
From: austin <austin@xilinx.com>
Date: Thu, 1 Apr 2010 07:54:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
Syms,

Peak to peak is peak to peak.  You can take as many (or as few) cycles
as you wish, but do not exceed the peak to peak jitter specification.
(p-p says nothing about jitter spectral content)

Of course if you move the clock edges (with respect to a perfect
mythical mathematical reference) over billions of clock cycles, you
can tolerate more than specified, but the specification is the
specification, and as such, it applies to the cycle to cycle can not
exceed the p-p, and the cycle to the 15th cycle can not exceed the p-
p, etc.  The p-p bounds any cycle to any cycle.

Austin

Article: 146904
Subject: Re: Which is the most beautiful and memorable hardware structure
From: "Andy \"Krazy\" Glew" <ag-news@patten-glew.net>
Date: Thu, 01 Apr 2010 08:35:23 -0700
Links: << >>  << T >>  << A >>
On 3/30/2010 9:15 PM, glen herrmannsfeldt wrote:
> In comp.arch.fpga "Andy \"Krazy\" Glew"<ag-news@patten-glew.net>  wrote:
>> The two hardware datastructures supporting out of order execution:
>
>> Reservation stations.
>
>> And, less beautifully, the register renaming map.
>
> Both from the IBM 360/91, as far as I know.
>
> S/360 has only four floating point registers, so register
> renaming was pretty important for out-of-order execution.
>
> OK, how about imprecise interrupts?
>
> -- glen


I never really knew how the 360/91 did register renaming.   I don't think it used a RAM style map.  I think it used CAMs.

I actually asked Tomasulo this, but he never really answered the question.

Article: 146905
Subject: Re: Which is the most beautiful and memorable hardware structure
From: "Andy \"Krazy\" Glew" <ag-news@patten-glew.net>
Date: Thu, 01 Apr 2010 08:46:35 -0700
Links: << >>  << T >>  << A >>
> In article<houi8s$rdm$1@naig.caltech.edu>,
>> OK, how about imprecise interrupts?

Not a good idea.

Article: 146906
Subject: help with ISE+modelsim XEIII
From: "totohaha" <wuxianguk@n_o_s_p_a_m.hotmail.com>
Date: Thu, 01 Apr 2010 10:47:19 -0500
Links: << >>  << T >>  << A >>
I have a System Generator design and I have build it to ""HDL Netlist", and
select the "Create testbench" in Sys Gen. Then I use ISE to do the
post-route simulation. My Enviroment: 
ISE 10.1.03 with service pack 3
Modelsim XEIII with pre-compiled library. 


Now I have following errors: 

# Loading simprim.x_buf(x_buf_v)
# Loading simprim.x_obuf(x_obuf_v)
# ** Error: (vsim-3733) ./netgen/par/test_cw_timesim.vhd(1487: No default
binding for component at 'gateway_out_10_obuf'.
# (Generic 'tpd_gts_o' is not on the entity.)
# Region: /test_tb/sysgen_dut/gateway_out_10_obuf
# ** Error: (vsim-3733) ./netgen/par/test_cw_timesim.vhd(14886): No default
binding for component at 'gateway_out_11_obuf'.
# (Generic 'tpd_gts_o' is not on the entity.)
# Region: /test_tb/sysgen_dut/gateway_out_11_obuf
# ** Error: (vsim-3733) ./netgen/par/test_cw_timesim.vhd(14894): No default
binding for component at 'gateway_out_12_obuf'.
# (Generic 'tpd_gts_o' is not on the entity.)
# Region: /test_tb/sysgen_dut/gateway_out_12_obuf
# ** Error: (vsim-3733) ./netgen/par/test_cw_timesim.vhd(14902): No default
binding for component at 'gateway_out_13_obuf'.
# (Generic 'tpd_gts_o' is not on the entity.)
# Region: /test_tb/sysgen_dut/gateway_out_13_obuf
# ** Error: (vsim-3733) ./netgen/par/test_cw_timesim.vhd(14910): No default
binding for component at 'gateway_out_14_obuf'.
# (Generic 'tpd_gts_o' is not on the entity.)
# Region: /test_tb/sysgen_dut/gateway_out_14_obuf
# ** Error: (vsim-3733) ./netgen/par/test_cw_timesim.vhd(1491: No default
binding for component at 'gateway_out_15_obuf'.
# (Generic 'tpd_gts_o' is not on the entity.) 

# Loading simprim.x_dsp48e(x_dsp48e_v)
# Loading simprim.x_srlc16e(x_srlc16e_v)
# Loading simprim.x_ckbuf(x_ckbuf_v)
# Loading simprim.x_roc(x_roc_v)
# Loading simprim.x_toc(x_toc_v)
# Loading instances from ./netgen/par/test_cw_timesim.sdf
# Loading timing data from ./netgen/par/test_cw_timesim.sdf
# Error loading design
# Error: Error loading design 
# Pausing macro execution 
# MACRO ./pn_postpar.do PAUSED at line 15


Note that my pn_postpar.do file is generated by Sys Gen automatically as
follows, the line 15 is the vsim command.


-- If you see error messages concerning missing libraries for
-- XilinxCoreLib, unisims, or simprims, you may not have set
-- up your ModelSim environment correctly. See the Xilinx
-- Support Website for instructions telling how to compile
-- these libraries.

vlib work

vcom -93 -nowarn 1 -novopt
"D:/Xilinx/10.1/DSP_Tools/common/bin/../../sysgen/hdl/conv_pkg.vhd"
vcom -93 -nowarn 1 -novopt
"D:/Xilinx/10.1/DSP_Tools/common/bin/../../sysgen/hdl/xlclkprobe.vhd"
set env(PERL5LIB) {}
exec "D:/Xilinx/10.1/ISE/bin/nt/unwrapped/xilperl.exe"
"D:/Xilinx/10.1/DSP_Tools/common/bin/../../sysgen/scripts/probeclk.pl" -f
/netgen/par/test_cw_timesim.vhd
vcom -nowarn 1 -novopt ./netgen/par/test_cw_timesim.vhd
vcom -93 -nowarn 1 -novopt test_tb.vhd
vsim -novopt -L work -t ps -sdftyp
/sysgen_dut=./netgen/par/test_cw_timesim.sdf test_tb
view wave
add wave *
view structure
view signals
run 6875.000000 ns


Anybody have ideas?

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

Article: 146907
Subject: Re: Which is the most beautiful and memorable hardware structure in a CPU?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 1 Apr 2010 18:07:42 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga "Andy \"Krazy\" Glew" <ag-news@patten-glew.net> wrote:
(snip)
 
> I never really knew how the 360/91 did register renaming.   
> I don't think it used a RAM style map.  I think it used CAMs.
 
> I actually asked Tomasulo this, but he never really answered 
> the question.

Never having had anyone to ask, but only read about it in books,
that sounds about right.  

The explanation I have seen for the CDB, common data bus, was
that results come out broadcast to all possible destinations.
Those destinations expecting a result from that source accept it.
Possible destinations are registers, reservation stations
(for adders or mutliply/divide), or to be written to main memory.
Sources are results from arithmetic units, or data read from 
(750 ns, 16 way interleaved) main memory.

Among the not so obvious ones, if you store to memory and then
refetch, register renaming will detect the same address is
being used and go directly to the source.  (No cache on the
360/91, it originated on the 360/85.)  

-- glen

Article: 146908
Subject: Re: Spartan 3E: MAX_STEPS as a function of CLKIN frequency
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 1 Apr 2010 12:59:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 10:49=A0am, austin <aus...@xilinx.com> wrote:
> John,
>
> 3E was its own animal, with a completely different and unique DCM
> design, unlike all of the others. =A0I immediately posted that the 256
> steps was a mistake in my original post.
>
> 3E DCM had some real advantages, but we went back to the "old" DCM
> design.
>
> The experience gained in the design of PLLs for the MGTs, led to some
> very intense 'digitally calibrated PLL' to the point where in V6, they
> are not called DCM nor PLL...as they are not really either (MMCM).
>
> Austin

Thanks and my apologies.  I see now what you meant with your
correction.  The language wasn't clear on what you meant through this
text medium, the newsgroup.  I'm sure I would have known what you
meant if we were discussing verbally.

As tough as the S3E variable phase was for the middle of that project,
I really liked the feature and was impressed by the performance.

One fun experiment: feed the output of the DCM to a carry chain (using
a toggle flop) and clock the output of the chain with the original
reference clock, marking the recovered transition point in the carry
chain with an XOR.  Visualize the result with LEDs.  One spot is
typically lit up along the carry chain.  Every increment of the phase
isn't always a visible change, but the average I saw was 4 phase
increments to move one position on the carry-chain readout if it's
between slices, 2 phase increments to see the transition move if it's
within a slice.  I think I did this on the Spartan3E starter kit using
the 8 LEDs and the rotary dial.  Fun, fun to see it in action.

The controllability was solid, the results pretty darned pristine.

Article: 146909
Subject: XSVF player that writes V4 key
From: "ucfchuck" <ucfchuck@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Thu, 01 Apr 2010 15:35:22 -0500
Links: << >>  << T >>  << A >>
i wrote an xsvf player bridged across a pc and an fx2lp to deliver the
program code to a prom through a gpio port on the fx2lp. it works fine and
will reprogram a system and will program a new system. but when it is an
encrypted sourcefile the key has to already be in the system, and i cannot
program it from the player. there are no new commands that i can see which
are not in the regular program file, though the xsvf does show some strange
duplication of commands, im guessing to send the device into the special
programming mode. 

point is i can program 7+MB of data over this player just fine, but
700bytes wont work? theres obviously something there that i cant find in
any documentation, as the key is programmed fine when i use impact and the
cable to play the xsvf file. i cant exactly find out what is different bit
by bit as xilinx has their cable set to pseudo random delays so a scope is
just a pain. 

has anyone gotten through this mess before? whats the problem with writing
a key through the xsvf?	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 146910
Subject: Predefined MACRO's in XST v11.5
From: "vragukumar" <vragukumar@n_o_s_p_a_m.n_o_s_p_a_m.signalogic.com>
Date: Thu, 01 Apr 2010 15:45:27 -0500
Links: << >>  << T >>  << A >>
Hello,

I would like to know if XST v11.5 supports any predefined MACRO's. We are
particularly interested in a MACRO for the version of XST being used.

Thanks in advance,
Vikram.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 146911
Subject: Re: Spartan 3E: MAX_STEPS as a function of CLKIN frequency
From: austin <austin@xilinx.com>
Date: Thu, 1 Apr 2010 14:21:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
John,

No apology necessary.  I  posted something half-way "right" and then
followed with a terse correction.

The phase control in 3E was pretty neat, but it was a "solution
looking for a problem" (no one could think of any way to really
exploit it...).

I recently used a DCM with phase shift to measure the delay of a
critical path.  I use this information to control the supply voltage.

Although voltage scaling is not supported, one can save ~50% of the
power (static + dynamic) in the Virtex 5 1v core, by lowering the
voltage and keeping the voltage just where the device still works.  If
you have a fast corner part, you really save a lot of power.  If you
have a slow corner part, then the static power is very low, and even
at 1.0v you are still saving power (over the data sheet which has to
be set at the fastest part that could be shipped).

I control the power supply with a single IO pin, using a 5 bit PWM to
adjust the Vccint from 0.8 v to 1.04v (31 steps used, I don't use
00000).  So, a few LUTS, a few DFF, the logic runs off any clock you
have in your design, and the DCM, and one IO pin, some resistors and a
single capacitor to smooth out the PWM, and the supply goes up and
down as needed to keep the device happy (just meeting the TILO of the
speeds file), and saving power.

Now, I think that is useful, but I can't really get any traction
around here for the idea...

One of the down-sides is that below .95v, we do not specify anything
(nothing is guaranteed below 0.95v), so we would have to do a lot more
characterization.

Austin


Article: 146912
Subject: Re: Which is the most beautiful and memorable hardware structure in a
From: MitchAlsup <MitchAlsup@aol.com>
Date: Thu, 1 Apr 2010 15:22:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 1:07=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> The explanation I have seen for the CDB, common data bus, was
> that results come out broadcast to all possible destinations.

Do you realize that the length of this bus and the number of
destination nodes was one of the reasons the IBM machine topped out at
60ns while the CDC machines topped out at 27.5ns and could deliver 4
result (and one load) per cycle (as catch-up bandwidth).

Mitch


Article: 146913
Subject: Re: Predefined MACRO's in XST v11.5
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Thu, 1 Apr 2010 15:23:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 1:45=A0pm, "vragukumar"
<vragukumar@n_o_s_p_a_m.n_o_s_p_a_m.signalogic.com> wrote:
> Hello,
>
> I would like to know if XST v11.5 supports any predefined MACRO's. We are
> particularly interested in a MACRO for the version of XST being used.
>
> Thanks in advance,
> Vikram. =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

XST is a VHDL and Verilog synthesizer and will synthesis any HDL that
it is provided.  The term MACRO has its orgins in schematic design.

What are you really looking for?

Ed McGettigan
--
Xilinx Inc.

Article: 146914
Subject: Re: Predefined MACRO's in XST v11.5
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 1 Apr 2010 22:45:33 +0000 (UTC)
Links: << >>  << T >>  << A >>
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:
(snip)
 
> XST is a VHDL and Verilog synthesizer and will synthesis any HDL that
> it is provided.  The term MACRO has its orgins in schematic design.
 
> What are you really looking for?

It sounds like he is looking for something similar to what
the way the C preprocessor is used in C.  I believe that MACRO
has been used a lot longer than computerized schematic design,
back to the beginnings of assembly programming.

I believe that verilog has something similar to the C preprocessor,
I am not so sure about VHDL.

-- glen

Article: 146915
Subject: Re: Predefined MACRO's in XST v11.5
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Thu, 1 Apr 2010 16:02:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 3:45=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> (snip)
>
> > XST is a VHDL and Verilog synthesizer and will synthesis any HDL that
> > it is provided. =A0The term MACRO has its orgins in schematic design.
> > What are you really looking for?
>
> It sounds like he is looking for something similar to what
> the way the C preprocessor is used in C. =A0I believe that MACRO
> has been used a lot longer than computerized schematic design,
> back to the beginnings of assembly programming.
>
> I believe that verilog has something similar to the C preprocessor,
> I am not so sure about VHDL.
>
> -- glen

I almost struck the comment about schematics in my reply and I
probably should have.  I was thinking that the original poster might
be referring to the old Xilinx LogiBlox schematic macros that would be
automatically expanded  by the Xilinx tools.

Ed McGettigan
--
Xilinx Inc.

Article: 146916
Subject: Re: Spartan 6 PLL - Why such a strict input jitter requirement?
From: rickman <gnuarm@gmail.com>
Date: Thu, 1 Apr 2010 16:13:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 10:54=A0am, austin <aus...@xilinx.com> wrote:
> Syms,
>
> Peak to peak is peak to peak. =A0You can take as many (or as few) cycles
> as you wish, but do not exceed the peak to peak jitter specification.
> (p-p says nothing about jitter spectral content)
>
> Of course if you move the clock edges (with respect to a perfect
> mythical mathematical reference) over billions of clock cycles, you
> can tolerate more than specified, but the specification is the
> specification, and as such, it applies to the cycle to cycle can not
> exceed the p-p, and the cycle to the 15th cycle can not exceed the p-
> p, etc. =A0The p-p bounds any cycle to any cycle.
>
> Austin

Hmmm, do I understand what you are saying?  If I take you literally,
then the frequency would have to be spot on, right?  The accumulated
drift would add up over many cycles and violate any p-p jitter spec if
you state as being "any cycle to any cycle".  I guess it depends on
what you are using as a reference.  So what is the reference for
measuring jitter over many cycles?  Do you assume the nominal rate or
do you use the actual average clock period of the signal?

Rick

Article: 146917
Subject: Re: Predefined MACRO's in XST v11.5
From: d_s_klein <d_s_klein@yahoo.com>
Date: Thu, 1 Apr 2010 17:04:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 4:02=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Apr 1, 3:45=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>
>
> > Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> > (snip)
>
> > > XST is a VHDL and Verilog synthesizer and will synthesis any HDL that
> > > it is provided. =A0The term MACRO has its orgins in schematic design.
> > > What are you really looking for?
>
> > It sounds like he is looking for something similar to what
> > the way the C preprocessor is used in C. =A0I believe that MACRO
> > has been used a lot longer than computerized schematic design,
> > back to the beginnings of assembly programming.
>
> > I believe that verilog has something similar to the C preprocessor,
> > I am not so sure about VHDL.
>
> > -- glen
>
> I almost struck the comment about schematics in my reply and I
> probably should have. =A0I was thinking that the original poster might
> be referring to the old Xilinx LogiBlox schematic macros that would be
> automatically expanded =A0by the Xilinx tools.
>
> Ed McGettigan
> --
> Xilinx Inc.

I think I know what the original poster is asking after...

I have found some things that "just don't" synthesize properly with
ISE-11.  By that I mean that there are NO errors or additional
warnings, but the resulting chip is dead, where it wasn't dead with
version 10.

By having a synthesize-time flag, one could create two different
codes, and "if-def" according to which version of XST is being used.

eg:

`ifdef L.70  // this is 11.5
foo <=3D ~bar;
`else
foo <=3D !bar;
`endif

Then again, I'm only guessing about what the OP was asking after...

RK

Article: 146918
Subject: Re: Which is the most beautiful and memorable hardware structure
From: "Andy \"Krazy\" Glew" <ag-news@patten-glew.net>
Date: Thu, 01 Apr 2010 19:05:52 -0700
Links: << >>  << T >>  << A >>
On 4/1/2010 11:07 AM, glen herrmannsfeldt wrote:
> In comp.arch.fpga "Andy \"Krazy\" Glew"<ag-news@patten-glew.net>  wrote:
> (snip)
>
>> I never really knew how the 360/91 did register renaming.
>> I don't think it used a RAM style map.  I think it used CAMs.
>
>> I actually asked Tomasulo this, but he never really answered
>> the question.
>
> Never having had anyone to ask, but only read about it in books,
> that sounds about right.

All I know is that I proposed having a separate pipestage to rename registers, using a RAM (SRAM) table indexed by 
logical register number returning physical register number, in 1986 or 1987 - in Wen-mei Hwu's microprocessor design 
class - after he had taken us through Tomasulo and HPSm.

I.e. I proposed eliminating the CAMs, replacing them by a RAM and an additional pipestage.

The idea seemed new to everyone who encountered it. It was not universally accepted as good.  Indeed, I remember arguing 
with Tom Olson of AMD (if memory serves), who said that spending an extra pipestage was not a good idea.

I also talked to Mitch about it at around that time, although he was preoccupied with spreadsheets for the



> The explanation I have seen for the CDB, common data bus, was
> that results come out broadcast to all possible destinations.
> Those destinations expecting a result from that source accept it.
> Possible destinations are registers, reservation stations
> (for adders or mutliply/divide), or to be written to main memory.
> Sources are results from arithmetic units, or data read from
> (750 ns, 16 way interleaved) main memory.

Many people say that the CDB was an important invention.  I think it was a bad idea - long wires, CAMs.

Conceptually it is elegant, but implementation wise it is a bad idea.

The important thing is taking that conceptually elegant CAM-ful idea, and implementing it in an efficient non-CAM manner.

The modern style of register renaming accomplishes this - certainly for the registers, but also, depending on the 
system, for the reservation stations (if those are still being used).




> Among the not so obvious ones, if you store to memory and then
> refetch, register renaming will detect the same address is
> being used and go directly to the source.  (No cache on the
> 360/91, it originated on the 360/85.)

I'd love to see a reference for this.

I believe that a UWisc patent on this was one of the things that resulted in a big payment from Intel to UWisc.

Myself, I thought it was obvious.

Article: 146919
Subject: Re: Which is the most beautiful and memorable hardware structure in a
From: Robert Myers <rbmyersusa@gmail.com>
Date: Thu, 1 Apr 2010 19:20:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 10:05=A0pm, "Andy \"Krazy\" Glew" <ag-n...@patten-glew.net>
wrote:

> Myself, I thought it was obvious.

There's your problem right there, Andy.  Everyone else will say:

1. It's already been done (heard way too many times in this forum).

2. It was obvious (emphasis on the past tense).

People answering either (1) or (2) assume that everything that can be
thought of is already in textbooks.  That's how they got to where they
are.

Robert.


Article: 146920
Subject: Re: Which is the most beautiful and memorable hardware structure in a
From: MitchAlsup <MitchAlsup@aol.com>
Date: Thu, 1 Apr 2010 19:48:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 9:05=A0pm, "Andy \"Krazy\" Glew" <ag-n...@patten-glew.net>
wrote:
> I also talked to Mitch about it at around that time, although he was preo=
ccupied with spreadsheets for the

Any chance you could complete this sentance?

Perhaps from {88100, 88110, 88120, crazy, insane, Asilomar
participants, Hot Chips participants, all of the preceeding?}

Mitch

Article: 146921
Subject: Re: Spartan 6 PLL - Why such a strict input jitter requirement?
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 1 Apr 2010 20:15:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 7:13=A0pm, rickman <gnu...@gmail.com> wrote:
> On Apr 1, 10:54=A0am, austin <aus...@xilinx.com> wrote:
>
> > Syms,
>
> > Peak to peak is peak to peak. =A0You can take as many (or as few) cycle=
s
> > as you wish, but do not exceed the peak to peak jitter specification.
> > (p-p says nothing about jitter spectral content)
>
> > Of course if you move the clock edges (with respect to a perfect
> > mythical mathematical reference) over billions of clock cycles, you
> > can tolerate more than specified, but the specification is the
> > specification, and as such, it applies to the cycle to cycle can not
> > exceed the p-p, and the cycle to the 15th cycle can not exceed the p-
> > p, etc. =A0The p-p bounds any cycle to any cycle.
>
> > Austin
>
> Hmmm, do I understand what you are saying? =A0If I take you literally,
> then the frequency would have to be spot on, right? =A0The accumulated
> drift would add up over many cycles and violate any p-p jitter spec if
> you state as being "any cycle to any cycle". =A0I guess it depends on
> what you are using as a reference. =A0So what is the reference for
> measuring jitter over many cycles? =A0Do you assume the nominal rate or
> do you use the actual average clock period of the signal?
>
> Rick

Bottom line, in my humble opinion: the PLL jitter spec STINKS.  The
PLL may be palatable, but the spec isn't.  Like comm systems, there's
a high frequency peak-to-peak jitter that should probably apply and a
20dB/decade climb to lower frequencies beyond a specific frequency
point.  This corresponds to a maximum phase comparator error when the
loop is trying to follow the significantly jittering signal.  "Wander"
is what they call jitter below 10 Hz in some comm systems.  We *can't*
be talking about peak-to-peak jitter down to 10 Hz.  That's just
ludicrous and points out specifically why this value needs to be more
properly specified.

Article: 146922
Subject: Re: Which is the most beautiful and memorable hardware structure in a
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 1 Apr 2010 21:28:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 10:20=A0pm, Robert Myers <rbmyers...@gmail.com> wrote:
> On Apr 1, 10:05=A0pm, "Andy \"Krazy\" Glew" <ag-n...@patten-glew.net>
> wrote:
>
> > Myself, I thought it was obvious.
>
> There's your problem right there, Andy. =A0Everyone else will say:
>
> 1. It's already been done (heard way too many times in this forum).
>
> 2. It was obvious (emphasis on the past tense).
>
> People answering either (1) or (2) assume that everything that can be
> thought of is already in textbooks. =A0That's how they got to where they
> are.
>

Textbooks?  Didn't you get the memo?  Everything that can be thought
of is on Google...or should I say Topeka ;)

KJ

Article: 146923
Subject: Re: Which is the most beautiful and memorable hardware structure in a CPU?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 2 Apr 2010 04:31:44 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga "Andy \"Krazy\" Glew" <ag-news@patten-glew.net> wrote:
(snip)
 
> All I know is that I proposed having a separate pipestage 
> to rename registers, using a RAM (SRAM) table indexed by 
> logical register number returning physical register number, 
> in 1986 or 1987 - in Wen-mei Hwu's microprocessor design 
> class - after he had taken us through Tomasulo and HPSm.  

> I.e. I proposed eliminating the CAMs, replacing them by a 
> RAM and an additional pipestage.

With the 360/91 system, though, values can easily have more than
one destination.   I suppose that could be done other ways,
too, but it is especially convenient that way.

> The idea seemed new to everyone who encountered it. It was 
> not universally accepted as good.  Indeed, I remember arguing 
> with Tom Olson of AMD (if memory serves), who said that 
> spending an extra pipestage was not a good idea.
 
> Many people say that the CDB was an important invention.  
> I think it was a bad idea - long wires, CAMs.
 
If the wires are too long, then add more pipeline stages along
the way.  With 750ns 16way interleaved core, though, the 91
wasn't going to get much faster than 60ns.
 
> Conceptually it is elegant, but implementation wise it is a bad idea.
 
> The important thing is taking that conceptually elegant 
> CAM-ful idea, and implementing it in an efficient non-CAM manner.
 
> The modern style of register renaming accomplishes this - 
> certainly for the registers, but also, depending on the 
> system, for the reservation stations (if those are still 
> being used).

Logic was much more expensive then, than now, so the
tradoffs are likely different.  If you used RAM tables
with more than one entry for each source, you could do 
multiple destinations easily.  
 
>> Among the not so obvious ones, if you store to memory and then
>> refetch, register renaming will detect the same address is
>> being used and go directly to the source.  (No cache on the
>> 360/91, it originated on the 360/85.)
 
> I'd love to see a reference for this.

There is an issue of the IBM Journal of Research and 
Development pretty much devoted to the 91.  I believe 
it is in there.  The 91 is pretty much a favorite for
books on pipelined processor design, mostly referencing
that journal issue.
 
> I believe that a UWisc patent on this was one of the things 
> that resulted in a big payment from Intel to UWisc.
 
> Myself, I thought it was obvious.

-- glen

Article: 146924
Subject: Re: FMC Boards ?
From: luudee <rudolf.usselmann@gmail.com>
Date: Thu, 1 Apr 2010 22:30:33 -0700 (PDT)
Links: << >>  << T >>  << A >>

Hi,

so I want ahead and placed the order with Avnet, and they are telling
both boards
are on back order. No shipping date is given ...

See, that's why I hate doing business with Avnet ! Now that they are
sole distributor,
I suspect things will get even worth ...

Cheers,
rudi



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