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
ratemonotonic wrote: > Hi all , > > I am devoloping software fro microblaze using XPS and I dont have > enough resources for a watchdog timer. > > I want to reset the FPGA after n number of error conditions have > occured in software. Whats the most reliable way to reboot the Xilinx > Spartan 3 FPGA? That path pre-supposes the system is lame, but no so lame it cannot run the Quality decision software. ie it only gives partial coverage. Common parts are Reset/Watchdog devices, in SOT23-5 packages, and these will generate a repeating Reset Pulse on failure to trigger faster than a certain rate. Some even have window-watchdogs. You can, of course, still trigger this in SW, anytime you want, by turning off the trigger. -jgArticle: 132251
On May 19, 2:38=A0pm, Pablo <pbantu...@gmail.com> wrote: > this is my code: > > entity Top_Module is > =A0 =A0 =A0 =A0 port ( > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 o_DSP0 =A0 =A0 =A0 =A0 =A0: out =A0 =A0 My= RecordType > =A0 =A0 =A0 =A0 =A0 =A0 =A0 ); > end Top_Module; > > whe o_DSP0 is: > > type MyRecordType is record > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int4 =A0 =A0 =A0 =A0 =A0 =A0: std_logic; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int5 =A0 =A0 =A0 =A0 =A0 =A0: std_logic; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int6 =A0 =A0 =A0 =A0 =A0 =A0: std_logic; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int7 =A0 =A0 =A0 =A0 =A0 =A0: std_logic; > =A0 =A0 =A0 =A0 end record; > > --------------- > > How is o_DSP0 declared in ucf file? Most likely the 'o_DSP0' signal will get synthesized to a 'flattened' set of names like 'o_DSP0_int4', 'o_DSP0_int5', etc. Check the output of your synthesis result to find out how the record type signal elements got renamed. KJArticle: 132252
On 19 May, 18:51, Peter Alfke <pe...@xilinx.com> wrote: > On May 16, 1:25 pm, Peter Alfke <pe...@xilinx.com> wrote: > > > > > On May 16, 8:07 am, austin <aus...@xilinx.com> wrote: > > > > Rate, > > > > Why do you need to reset the FPGA after some number of software errors? > > > Won't the software errors just re-occur? How does resetting > > > (restarting) the FPGA affect the software? > > > > To start over, forgetting everything, the best way is to pull PROG > > > (low). Tying an output of the same FPGA to the PROG line input is not > > > something we can easily recommend, as unless we really have it tested, > > > that is a race condition (as the first thing that happens when PROG is > > > pulled low, is all IOs go tristate!). > > > > I believe this works for some parts...and perhaps Peter will chime in > > > and let me know which one(s). > > > > Austin > > > To re-configure, you must pull down PROG for a certain length of > > time,expressed in microseconds.If you use one FPGA output to do this, > > you face a dilemma: Once reconfiguration starts, every output is being > > 3-stated, which violated the min PRG=Low time requirement.In older > > parts, this self-triggering worked reliably "by design", since both > > reconfiguration and 3-stating were controlled by a common latch. Once > > set, there was no way to stop configuration. > > This nice design was changed in some of the Virtex and probably also > > in some of the Spartan parts, just because the rationale for the > > previous design methodology was forgotten (its impact had never been > > officially documented anyhow). I'll try to find out, once and for all, > > which parts are designed which way. > > In future parts we intend to re-institute the old design method, since > > it offers one unbeatable advantage... > > Peter Alfke > > In Spartan-3 and Spartan 3E you need an external delay. > In Spartan3A and its derivatives (AN, DSP and future devices) the safe > operation is guaranteed by design: just use one output to drive PROG > Low. > Virtex, Virtex-II and Virtex-4 need an external delay. > Virtex-5 has an internal controller that can start re-configuration > (see Config User Guide, page 145). > Peter Alfke Thanks peter ,it is very helpful to know. We have constructed a delay circuit and it works fine. ofcourse we dont realy want to reset the FPGA in the real system. But this will buy us valuable time , where we can perfect the hardware. BR RateArticle: 132253
John, If you want some real entertainment: http://www.pldesignline.com/showArticle.jhtml?articleID=207000972 AustinArticle: 132254
input: Asynchronous, non-fix width, non-fix frequeny(but equal or smaller than 30 Mhz), something like random fast signal coming in. System clock is only 40MHz, What can I latch the "rising" edge of the input and synchronize it and don't get into big trouble of Metastability? Since the input freq is very near the System clock and Asynchronous don't have a clock signal coming in. is it possible that connecting the input signal directly to FF clock then following with a negative clk edge FF then positive clk edge FF? will it make any trouble and how to solve it?Article: 132255
John Adair wrote: > Altera have put out a press release announcing Stratix IV. Handbook > http://www.altera.com/literature/hb/stratix-iv/stx4_5v4.pdf. > Interestingly it's gone 40nm and does not appear to have a true 3.3V > compatability so buy your shares in manufacurers of bus switches now. Only partially. They do not state a Typical 3.3V, but they do say this The Abs Max spec 3.75V, V @ IO spec 3.6V The overshoot even gives a rather strange/interesting Volts/Time plot, where 4V overshoot is allowed 100% time, but 4.45V is limited to 1% of the time. What they do NOT say, is what happens if the 4.45V is there for 2% of the time :) Does the device a) Fry immediately it exceeds the 1.080% time allowance ? (Their precision is impressve!) b) Think about it for a while, then Fry ? c) Suffer a gradual leakage degradation, so it exceeds the 10uA spec, after the Volt-Time threshold. d) If c) then can the device fail, or just drift out of spec, and does that drift have a limit ? Lifetime of device ? Err ?! - They give an example of 10 years, but what should one do for a 5 year, or 20 year design life ? There is some underlying mechanism they are trying to spec here, but would it not make more sense, to identify that mechanism, than use this rather silly (partial) table, that raises more questions than it answers ? -jgArticle: 132256
Clemens wrote: > A different seed for each power-up would have been nice. Here's a method I've used for this in the past: Create a ring oscillator that can be stopped by some other bit. The ring oscillator drives a 2-bit ripple counter. Once the FPGA clock starts up, count off say 1 second's worth pulses of your high speed system clock and then disable the ring oscillator. The ripple counter will now have your 4-bit random value. This method relies on slight differences in the ring osc rate due to heating, etc. to add up over 1 second at startup. You might need to experiment with adding buffers (and make sure the tools don't remove them) and such to make sure the ring osc rate is not too high. -JeffArticle: 132257
Hello,
I ran into a bizarre state machine problem last week. I had a fairly
simple state machine written in VHDL, with an enumerated type and 5
states. The code is of the form :
if clock'event and clock='1' then
. . .
if state = a then
if inputa = '1' then
state <= b;
outputa <= '1';
end if;
end if;
if state = b then
. . .
the whole thing is synchronous, running at 40 MHz on a Spartan 2E,
except a couple external inputs such as the "inputa" above.
What I was seeing was the state machine locking up, so I added a process
to decode the valid states and send them to LEDs. I could see that the
lockups left signal state in some non-valid condition, ie. NOT one of
the enumerated values of the type.
I theorized it was encoding this as "one hot" as the software was set.
So, I forced the enumeration to have specific binary-coded values, and
enumerated all 8 possible codes, providing an if for the unused states
to go back to the reset state. This fixed the problem as far as I can
tell. I think this is telling me that in the "one hot" mode, it was
somehow getting more than one bit set true at a time.
Well, I was careful to set up the if's for each specific state to have
nested ifs in such a way so that any combination of input conditions
could only satisfy one of the lowest nested ifs. So, I just can't
figure out how it could possibly set more than one bit hi at a time.
There was a state where it could assign 2 different states values to
state, depending on the ifs. But, if all the ifs were nested, it could
never try to assign both values at the same time on the same clock.
But, that seems to be what was happening. The software is ISE 4.2
(I am still supporting some 5V Spartan stuff, and I'm also cheap).
Any hints about what was happening would be greatly appreciated!
Jon
Article: 132258Jon Elson wrote: > <snip> > the whole thing is synchronous, running at 40 MHz on a Spartan 2E, > except a couple external inputs such as the "inputa" above. > <snip> That right there could be your problem. If those inputs aren't synchronous then you could get into some trouble if they change just before a clock edge happens. Some of your state machine flops get the new message, some get the old one, and you've magically got an illegal state. Can you register those signals for a clock before you use them? -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 132259
> I need to interconnect two or four FPGAs on a PCB, and I am looking Why not just a bigger FPGA ? > at the prospect of designing these boards myself. If any one has done > this, I would be grateful if you could provide some pointers, > especially links to websites that have this information. I would > probably be using the Xilinx Virtex II A message of hope : I just built a proto with a Spartan-3E 500, SDRAM, Ethernet MAC, had never designed a 4 layer board before, and it worked. Everything works. The only problem was the JTAG which turned out to be a faulty parallel cable. Ironically hand soldering the PQ208 was a lot easier (5 minutes) than debugging the JTAG (two days). > I don’t know how to start this – but I have a few questions. Is it > possible for me to simulate the setup between FPGAs connected on a PCB > board. Or is it possible for me to bread board the FPGA – I have not Bread board ? Nope. Fire up Altium, make a PCB, and use for instance protoexpress.com, or get a readymade Spartan board from Enterpoint, etc. Actually you don't really need breadboarding... the FPGA will work. It's your switchmode regulator and other crap that won't work. > heard of this though. I have looked at the manual of the Virtex II, > and there are a large numbers of pins – I have yet to figure out which > pins I need to power at the minimum to get this to work. Powering all the power pins seems like a good idea... > So I don’t > want to start laying out a PCB Board immediately. > > I would be requiring significant on board communication – but I don’t > think I need the Rocket IOs that are available with Virtex4 – the > simple LVDS would do for me I guess. Is there a way for me to test > this aspect before actually putting it on the PCB?? As long as you have a FPGA and traces that go to it, you can make it work ;) Sleeping with the xilinx datasheets is a good idea too.Article: 132260
Rob Gaddi wrote: > Jon Elson wrote: > > > <snip> >> the whole thing is synchronous, running at 40 MHz on a Spartan 2E, >> except a couple external inputs such as the "inputa" above. > > <snip> > > That right there could be your problem. If those inputs aren't > synchronous then you could get into some trouble if they change just > before a clock edge happens. Some of your state machine flops get the > new message, some get the old one, and you've magically got an illegal > state. > > Can you register those signals for a clock before you use them? In addition to registering all inputs, you also should make sure that the state machine is initialized with a synchronous reset after your DLLs have locked. -JeffArticle: 132261
"Jon Elson" <elson@wustl.edu> wrote in message news:483200F4.3090002@wustl.edu... > > the whole thing is synchronous, running at 40 MHz on a Spartan 2E, except > a couple external inputs such as the "inputa" above. > Hi Jon, That's your problem! You have a one hot state machine with five states. This is implemented as five flipflops(FF). Your external inputs are asynchronous, and so if their transitions happen to be close to the clock transition, you wil have a race condition where the signal can get to one/some FF/s, but not others. Try this link http://en.wikipedia.org/wiki/Race_condition Cheers, Syms. p.s. For completeness, I should mention there is a difference between race hazards and metastability. Your circuit can suffer from both, but in your case the race condition is many orders of magnitude more observable than the 'm' word! See CAF passim!Article: 132262
They've also released Hardcopy-IV, including serdes and PCI-e. Why bother
with ASICs...
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 132263
On 2008-05-20, fazulu deen <fazulu.vlsi@gmail.com> wrote:
> I would like to know how these statements(for,while,do while) are
> implemented as logic design(EDIF and constraints) in FPGA device?? .
>
> Though FOR loop is synthesizable , it is always advised that FOR loops
> are not to be used in RTL coding. This is because it consumes lot of
> resources (like area etc)whether XST will not optimize it before
> targetting to FPGA device???
There is nothing magical with for and while loops in a synthesized
design. The synthesizer will simply unroll the loop for you. If
you know this you should easily be able to tell if a for loop is
applicable in your particular case.
For example, if you would like to write something like this in
Verilog a for loop is very suitable to do it:
// Bit reverse the signal:
always @* begin
foo[0] = bar[63];
foo[1] = bar[62];
foo[2] = bar[61];
// Kind of boring to write this without a for loop...
However, lets say that you have an array with 512 values in a
memory and you want to calculate the sum of all values:
always @* begin
sum = 0
for(i=0; i < 512; i = i + 1) begin
sum = sum + mem[i];
end
end
This is going to be hugely expensive in terms of hardware to
implement as you will end up with 512 adders and force your
memory to be implemented using flip-flops instead of a blockram.
In this case it is probably a much better idea to write a small
state machine to sum the values. It will take around 512 clock
cycles unless you do something clever like reading several values
at a time, but the footprint will be much more reasonable.
/Andreas
Article: 132264On May 19, 3:10=A0pm, Aiken <aikenp...@gmail.com> wrote: > input: Asynchronous, non-fix width, non-fix frequeny(but equal or > smaller than 30 Mhz), something like random fast signal coming in. > System clock is only 40MHz, > > What can I latch the "rising" edge of the input and synchronize it and > don't get into big trouble of Metastability? > Since the input freq is very near the System clock and Asynchronous > don't have a clock signal coming in. > is it possible that connecting the input signal directly to FF clock > then following with a negative clk edge FF then positive clk edge FF? > will it make any trouble and how to solve it? Synchronizing a 30 MHz signal with a roughly 40 MHz clock will generate an uncontrollable extra metastable delay of a few ns occasionally. But an extra 4 ns only once per many thousand years, statistically. You really do not have to worry about metastability. At ten times higher frequencies, you would run into problems... Se my Xilinx appnote XAPP094... Peter AlfkeArticle: 132265
On May 19, 7:30 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Sun, 18 May 2008 11:25:15 +0100, Jonathan Bromley
>
>
>
> <jonathan.brom...@MYCOMPANY.com> wrote:
> >On Sun, 18 May 2008 08:22:24 +0100, Brian Drummond wrote:
>
> >>I wrote: VHDL is not a dynamically typed language; you can't stretch and
> >>shrink subtypes e.g. ranges during run time.
>
> >>Which makes sense if you think about its orientation as a hardware
> >>language; it is difficult to stretch and shrink registers or counters
> >>after synthesis.
>
> >Yes, but subprograms (procedures and functions) are dynamically
> >elaborated: all their arguments, and their local variables, are
> >constructed dynamically at the moment of invocation. This is
> >what allows you to handle unconstrained arguments so elegantly.
> >For synthesis, the tool must convince itself that each subprogram
> >call is in a context in which the tool can statically determine
> >what will get elaborated; in other words, you effectively get
> >a new static instance of each subprogram for each distinct
> >invocation.
>
> Absolutely; I didn't mean anything different.
>
> I possibly misread Rickman's post; that he was re-calling the function
> for a different value of the same variable in the same instance of the
> same process. Which is not clear is the case.
That's a lot of sames... I'm not sure so here is the line that was
causing the error, at least I think this is it.
report "Read " &
" Addr " & to_hex_str(AddrWd, 2) &
" Read data " & to_hex_str(DataWd, 4) &
CR & LF severity NOTE;
As a work around I just converted the SLVs to ints like this,
to_int(AddrWd) and a different function was invoked that works
differently.
> Otherwise, I agree, it looks like a bug.
>
> I have found problems with ISE incorrectly synthesising different calls
> to a procedure in the same process so a similar bug in their simulator
> is credible.
>
> >Alternatively, there may be other ways to get your
> >type conversion, saving you the trouble of fighting
> >a possibly buggy FMF package. Converting a SLV to
> >its hex text representation is easy enough.
>
> That's why I was suggesting a static range, and using the parameter's
> length attribute to determine the number of digits.
The function *does* use the parameter's length attribute to set the
number of digits. Maybe I misunderstand what you mean. Here is the
initial code of the function.
function to_hex_str(x : std_logic_vector;
rtn_len : natural := 0;
justify : justify_side := right;
basespec : b_spec := yes) return
string is
-- will return x'length/4
variable nxt : positive := nextmultof(x'length,4);
variable int : std_logic_vector(1 to nxt):= (others => '0');
variable ptr : positive range 1 to (nxt/4)+1 := 1;
variable r : string(1 to nxt/4):=(others=>'$');
subtype slv4 is std_logic_vector(1 to 4);
variable slv4_val : slv4;
begin
The length of the input string 'x' is used to define nxt which in tern
is used to define everything else.
I still don't have another simulator running, but I might later this
week.
Rick
Article: 132266Hi, DS302 - Pg 11, Table 12, Note 1 says "The maximum VTRX is 1.26V when bypassing the internal AC coupled VICM. VTRX must be less than or equal to AVCCAUXRX". How is VTRX (Termination) related to AVCCAUXRX (Rocket IO) ? If this guideline is not followed, what effects it might have ? Thanks AkshatArticle: 132267
hai, I learned from the Xilinx manual that for,while do statements are synthesized in XST.. I would like to know how these statements(for,while,do while) are implemented as logic design(EDIF and constraints) in FPGA device?? . Though FOR loop is synthesizable , it is always advised that FOR loops are not to be used in RTL coding. This is because it consumes lot of resources (like area etc)whether XST will not optimize it before targetting to FPGA device??? As wait() is not supported for synthesis wat should i use instead of wait()?? regards, fazArticle: 132268
Year I did, here is my MHS file: PARAMETER VERSION = 2.1.0 PORT fpga_0_RS232_DCE_RX_pin = fpga_0_RS232_DCE_RX, DIR = I PORT fpga_0_RS232_DCE_TX_pin = fpga_0_RS232_DCE_TX, DIR = O PORT fpga_0_RS232_DTE_RX_pin = fpga_0_RS232_DTE_RX, DIR = I PORT fpga_0_RS232_DTE_TX_pin = fpga_0_RS232_DTE_TX, DIR = O PORT sys_clk_pin = dcm_clk_s, DIR = I, SIGIS = CLK, CLK_FREQ = 50000000 PORT sys_rst_pin = sys_rst_s, DIR = I, RST_POLARITY = 1, SIGIS = RST BEGIN proc_sys_reset PARAMETER INSTANCE = proc_sys_reset_0 PARAMETER HW_VER = 2.00.a PARAMETER C_EXT_RESET_HIGH = 1 PORT Slowest_sync_clk = sys_clk_s PORT Dcm_locked = Dcm_all_locked PORT Ext_Reset_In = sys_rst_s PORT MB_Reset = mb_reset PORT Bus_Struct_Reset = sys_bus_reset PORT MB_Debug_Sys_Rst = Debug_SYS_Rst END BEGIN microblaze PARAMETER HW_VER = 7.00.a PARAMETER INSTANCE = microblaze_0 PARAMETER C_INTERCONNECT = 1 PARAMETER C_DEBUG_ENABLED = 1 PARAMETER C_AREA_OPTIMIZED = 1 BUS_INTERFACE DLMB = dlmb BUS_INTERFACE ILMB = ilmb BUS_INTERFACE DPLB = mb_plb BUS_INTERFACE IPLB = mb_plb BUS_INTERFACE DEBUG = microblaze_0_dbg PORT RESET = mb_reset PORT INTERRUPT = Interrupt END BEGIN plb_v46 PARAMETER INSTANCE = mb_plb PARAMETER HW_VER = 1.00.a PORT PLB_Clk = sys_clk_s PORT SYS_Rst = sys_bus_reset END BEGIN bram_block PARAMETER INSTANCE = lmb_bram PARAMETER HW_VER = 1.00.a BUS_INTERFACE PORTA = ilmb_port BUS_INTERFACE PORTB = dlmb_port END BEGIN lmb_bram_if_cntlr PARAMETER INSTANCE = ilmb_cntlr PARAMETER HW_VER = 2.10.a PARAMETER C_BASEADDR = 0x00000000 PARAMETER C_HIGHADDR = 0x00003fff BUS_INTERFACE SLMB = ilmb BUS_INTERFACE BRAM_PORT = ilmb_port END BEGIN lmb_v10 PARAMETER INSTANCE = ilmb PARAMETER HW_VER = 1.00.a PORT LMB_Clk = sys_clk_s PORT SYS_Rst = sys_bus_reset END BEGIN lmb_bram_if_cntlr PARAMETER INSTANCE = dlmb_cntlr PARAMETER HW_VER = 2.10.a PARAMETER C_BASEADDR = 0x00000000 PARAMETER C_HIGHADDR = 0x00003fff BUS_INTERFACE SLMB = dlmb BUS_INTERFACE BRAM_PORT = dlmb_port END BEGIN lmb_v10 PARAMETER INSTANCE = dlmb PARAMETER HW_VER = 1.00.a PORT LMB_Clk = sys_clk_s PORT SYS_Rst = sys_bus_reset END BEGIN mdm PARAMETER INSTANCE = debug_module PARAMETER HW_VER = 1.00.a PARAMETER C_MB_DBG_PORTS = 1 PARAMETER C_USE_UART = 1 PARAMETER C_UART_WIDTH = 8 PARAMETER C_BASEADDR = 0x84400000 PARAMETER C_HIGHADDR = 0x8440ffff BUS_INTERFACE SPLB = mb_plb BUS_INTERFACE MBDEBUG_0 = microblaze_0_dbg PORT Debug_SYS_Rst = Debug_SYS_Rst END BEGIN clock_generator PARAMETER INSTANCE = clock_generator_0 PARAMETER HW_VER = 1.00.a PARAMETER C_EXT_RESET_HIGH = 1 PARAMETER C_CLKIN_FREQ = 50000000 PARAMETER C_CLKOUT0_FREQ = 50000000 PARAMETER C_CLKOUT0_PHASE = 0 PARAMETER C_CLKOUT0_GROUP = NONE PORT CLKOUT0 = sys_clk_s PORT CLKIN = dcm_clk_s PORT LOCKED = Dcm_all_locked PORT RST = net_gnd END BEGIN xps_uartlite PARAMETER INSTANCE = RS232_DTE PARAMETER HW_VER = 1.00.a PARAMETER C_BAUDRATE = 9600 PARAMETER C_DATA_BITS = 8 PARAMETER C_ODD_PARITY = 0 PARAMETER C_USE_PARITY = 0 PARAMETER C_SPLB_CLK_FREQ_HZ = 50000000 PARAMETER C_BASEADDR = 0x84020000 PARAMETER C_HIGHADDR = 0x8402ffff BUS_INTERFACE SPLB = mb_plb PORT RX = fpga_0_RS232_DTE_RX PORT TX = fpga_0_RS232_DTE_TX END BEGIN xps_uartlite PARAMETER INSTANCE = RS232_DCE PARAMETER HW_VER = 1.00.a PARAMETER C_BAUDRATE = 9600 PARAMETER C_DATA_BITS = 8 PARAMETER C_ODD_PARITY = 0 PARAMETER C_USE_PARITY = 0 PARAMETER C_SPLB_CLK_FREQ_HZ = 50000000 PARAMETER C_BASEADDR = 0x84000000 PARAMETER C_HIGHADDR = 0x8400ffff BUS_INTERFACE SPLB = mb_plb PORT RX = fpga_0_RS232_DCE_RX PORT TX = fpga_0_RS232_DCE_TX END BEGIN xps_bram_if_cntlr PARAMETER INSTANCE = xps_bram_if_cntlr_0 PARAMETER HW_VER = 1.00.a PARAMETER C_SPLB_NATIVE_DWIDTH = 32 PARAMETER C_BASEADDR = 0x84414000 PARAMETER C_HIGHADDR = 0x84417fff BUS_INTERFACE SPLB = mb_plb BUS_INTERFACE PORTA = xps_bram_if_cntlr_0_PORTA END BEGIN bram_block PARAMETER INSTANCE = bram_block_0 PARAMETER HW_VER = 1.00.a BUS_INTERFACE PORTA = xps_bram_if_cntlr_0_PORTA END BEGIN xps_timer PARAMETER INSTANCE = delay PARAMETER HW_VER = 1.00.a PARAMETER C_BASEADDR = 0x84410800 PARAMETER C_HIGHADDR = 0x844109ff BUS_INTERFACE SPLB = mb_plb PORT Interrupt = delay_Interrupt END BEGIN xps_intc PARAMETER INSTANCE = xps_intc_0 PARAMETER HW_VER = 1.00.a PARAMETER C_BASEADDR = 0x84412000 PARAMETER C_HIGHADDR = 0x844121ff BUS_INTERFACE SPLB = mb_plb PORT Intr = delay_Interrupt PORT Irq = Interrupt ENDArticle: 132269
On 19 Mai, 08:28, kris2552 <muralee.vkris...@gmail.com> wrote: > could anybody please explain me ....whether is there any chance of > clock skew being greater than or equal to the timeperiod of the clock? > If so,what are the effects? Any explaination would be deeply > appreciated..... a) Please answer yourself, what would be necessary to prevent Clk-Skew beeing greater or equal the timeperiode of clock. b) A simplified calculation for max clk frequency is Fmax=1/(signal_delay + skew_delta) You should be aware that skew_delta may be >0 or <0. bye ThomasArticle: 132270
ThanksArticle: 132271
Jim They say somewhere I saw that 3.3V operation the bank voltage is recommended to be 3.0V so that the protection diodes work. It's probably less of a problem the way thay have done it than what Xilinx did in the early Spartan-3 in that it can take a 3.3V driven input. There s not a lot of margin though if all the power supply tolerances are taken into account. John Adair Enterpoint Ltd. On 19 May, 23:11, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > John Adair wrote: > > Altera have put out a press release announcing Stratix IV. Handbook > >http://www.altera.com/literature/hb/stratix-iv/stx4_5v4.pdf. > > Interestingly it's gone 40nm and does not appear to have a true 3.3V > > compatability so buy your shares in manufacurers of bus switches now. > > Only partially. > They do not state a Typical 3.3V, but they do say this > > The Abs Max spec 3.75V, > V @ IO spec 3.6V > > The overshoot even gives a rather strange/interesting Volts/Time > plot, where 4V overshoot is allowed 100% time, but 4.45V is > limited to 1% of the time. > > What they do NOT say, is what happens if the 4.45V is there for 2% of > the time :) > > Does the device > a) Fry immediately it exceeds the 1.080% time allowance ? > (Their precision is impressve!) > b) Think about it for a while, then Fry ? > c) Suffer a gradual leakage degradation, so it exceeds > the 10uA spec, after the Volt-Time threshold. > d) If c) then can the device fail, or just drift out of > spec, and does that drift have a limit ? > > Lifetime of device ? Err ?! - They give an example of 10 years, > but what should one do for a 5 year, or 20 year design life ? > > There is some underlying mechanism they are trying to spec here, > but would it not make more sense, to identify that mechanism, > than use this rather silly (partial) table, that raises more > questions than it answers ? > > -jgArticle: 132272
On Mon, 03 Mar 2008 20:40:07 +0100, Antti <Antti.Lukats@googlemail.com> wrote: > here it is: > > 1) devices densities like in Spartan-3 (50..5000) > 2) devices packages like Spartan-3E (including QN132 !) or better > (microBGA 6x6 mm?) > 3) all good features of S3A/AN !! > 4) design security with OTP encryption key (like Lattice ECP2) > 5) other features as already planned by Xilinx Here's mine : * Easy one : - Schmitt trigger on the TCK line * New packages to make prototyping easier and to make the chips easier to use on simpler boards that are less expensive, would translate into costs saving for small / simple systems, and possibly more sales from Xilinx ! Examples : - Self-centering BGA : put a through-hole pin in each of the corners of the BGA, the PCB designer makes 4 holes on the PCB, and the part now can be placed by a drunk intern, instead of a megabuck BGA placing robot. No, strike that, make it only 3 holes, so you can't put it the wrong way in. - PQ208 : put thermal pad below connected to GND, remove all GND pins from package ; put other smaller "thermal pads" for the power supplies and get rid of the supply pins, you get 50 more IO on the package. - BGA usable on a 4-layer board with standard specs (6/6 track and standard holes), instead of 6-layer with super small holes : Solution 1 : remove pins in a cross pattern for escaping with much less vias Solution 2 : Two exterior rows of pins @ 1mm pitch or even 0.8mm pitch, and all internal pins at 1.27mm pitch, to allow vias between the pins even on a cheap PCB process Interior pins : * A bit more difficult : - FPGAs shouldn't have input-only pins... the spartan-3E is a bit annoying for this... I know it's a compromise with the IOBs space on die, then a better solution would be a simpler IOB, supporting less features (like only LVCMOS output from the bank's voltage, not all the IOStandards) but please get rid of those input-only pins - If you can't get rid of the input-only pins, on the BGA package put them all in the internal balls close to the chip's center so if the designer doesn't need them he can forget them and save on layers... - more decoupling caps inside the package * Other : Hard SDRAM controller (or DDR) core in the chip and stacked SDRAM chip in the package, or multi chip module... you get the idea ;) ARM core Hey it was supposed to be a wishlist right ? In all of those if I just ge a more noise-tolerant TCK input I'll be happy.Article: 132273
"Jeff Cunningham" <jcc@sover.net> wrote in message news:483200e3$0$11170$4d3efbfe@news.sover.net... > Clemens wrote: > >> A different seed for each power-up would have been nice. > > Here's a method I've used for this in the past: > > Create a ring oscillator that can be stopped by some other bit. The ring > oscillator drives a 2-bit ripple counter. > > Once the FPGA clock starts up, count off say 1 second's worth pulses of > your high speed system clock and then disable the ring oscillator. The > ripple counter will now have your 4-bit random value. > > This method relies on slight differences in the ring osc rate due to > heating, etc. to add up over 1 second at startup. You might need to > experiment with adding buffers (and make sure the tools don't remove them) > and such to make sure the ring osc rate is not too high. > > -Jeff Hi Jeff, I've heard that ring oscillators can phase lock to other clocks on the same die. What did you find? I came across this link that gives some insights into the pitfalls. http://warmcat.com/_wp/ Now, this guy really knows how to do random! http://inventgeek.com/Projects/alpharad/overview.aspx Cheers, Syms.Article: 132274
You could try to step through those functions with the debugger (GDB): compile the libraries with -g and -O0 options, set a breakpoint in xilkernel_main(), and set into the xilkernel_init() function. See also XAPP1037 for a really nice introduction to debugging Microblaze programs. Hope this helps, Guy.
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