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 99800

Article: 99800
Subject: Re: Linux on ml403
From: "beeraka@gmail.com" <beeraka@gmail.com>
Date: 29 Mar 2006 08:15:59 -0800
Links: << >>  << T >>  << A >>
Hi,
     I know this is a bad hack, but just disable the Xilinx INT
controller for now and then compile the kernel. After compiling the
kernel, please try downloading... I guess doing this way would atleast
narrow down the problem...

--
Parag


Article: 99801
Subject: Re: OpenSPARC released
From: Jason Zheng <jxzheng@gmail.com>
Date: Wed, 29 Mar 2006 08:30:24 -0800
Links: << >>  << T >>  << A >>
Art Stamness wrote:
<snip>
> My simple assertion is that the added layer of indirection provided by
> the "my_dff" construct, and the seperate wire containing the result,
> gives me things easily, that would require RTL changes in the above
> example.
> 
> Lets say I want to simulate my design and initialize all registers to a
> non-X state, just for simulations, just to see what would happen. I
> would swap in a different my_dff with the attribute that I want, it
> would change my compile script, but not my source code.
> 
Yes, I agree with you that it is easy to do this particular 
transformation with your style. However, it's not enough to convince me, 
as this transformation can also be easily done with the proper RTL 
style, if not easier. With one or two lines of regular expression 
code/shell script, I can mine through the entire source code and 
generate a big initial block, which I conveniently insert in the testbench.

To me, portability is greater with more abstraction in the code, because 
it gives synthesis tools greater freedom to implement the logic.

Article: 99802
Subject: FSL to VHDL interface
From: dale.prather@gmail.com
Date: 29 Mar 2006 08:35:25 -0800
Links: << >>  << T >>  << A >>
Hello,

I'm having great difficulty interfacing my FSL to my external (from
microblaze point of view) VHDL.  I want an FSL to communicate between
Microblaze and my external VHDL.  I want to be able to import the .xmp
file to my ISE project and then create the instantiation template
(wrapper) for the XMP file (*_stub.vhd).  In the file I need to see the
FSL control signals, data etc.  I cannot get this to happen.  I'm
thinking there needs to be some kind of interface VHDL inside of the
EDK project and then make those signals external.  Please offer any
help you can.  I'm frustrated.... at the end of my rope :).

Thanks,
Dale


Article: 99803
Subject: Re: Xilinx ISE DRC: An antenna found
From: "Gabor" <gabor@alacron.com>
Date: 29 Mar 2006 08:36:23 -0800
Links: << >>  << T >>  << A >>

Davy wrote:
> Hi all,
>
> After I use Xilinx ISE do Place & Round and generate bit file, I am
> confused with a DRC warning=E3=80=82
>
> "WARNING: DesignRules:7-Netcheck: An antenna was found on signal; this
> means that a branch of this signal is partially routed or has a routing
> stub".
>
> I found bit file with this DRC warning cannot work properly.
>
> But what's this signal connected to? A tri-state bus? Or this signal
> wire form a loop?
>
> Any suggestions will be appreciated!
> Best regards,
> Davy

You have to go back and look at the place & route report.  I'm
surprised
that this is a warning and not an error.  It sounds like the router
didn't
complete...


Article: 99804
Subject: Re: free synthesizer to synthesize VHDL to Actel 1280XL FPGA
From: praviendre@hotmail.com
Date: 29 Mar 2006 09:10:14 -0800
Links: << >>  << T >>  << A >>
Thanks mate, i did fill the form for the trial version. let see how its
gonna go !!

cheers !!!


Article: 99805
Subject: Re: Keystroke saving w/ IEEE.Numeric_Std
From: "JustJohn" <john.l.smith@titan.com>
Date: 29 Mar 2006 09:21:31 -0800
Links: << >>  << T >>  << A >>

Andy wrote:
> +1 for natural type on phase_ctr!
>
> Inside a process (sequential statements):
>
> phase <= (others => '0'); -- sequential statements
> phase(phase_ctr) <= '1';
>
> Or if phase is a natural too:
>
> phase <= 2**phase_ctr; -- sequential or concurrent assignment
>
> Andy

Doh! This is great. (Sometimes I scare myself by how I miss the
simplest things). Thanks Andy.

Any more examples of keystroke/eye/paper savers out there?


Article: 99806
Subject: Re: Stratum4E holdover
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Wed, 29 Mar 2006 19:49:30 +0200
Links: << >>  << T >>  << A >>
Austin Lesea schrieb:


> take a 20.000 MHz oscillator and generate exactly the 8 MHz reference 
> you need.  I used for the 2E clocks, the raw rubidium output, which was 
> 50.2037(etc) MHz (basically every rubidium is shlightly different, but 
> they don't drift very much <1E-12, and some don't drift at all! - tested 
> them for 8 months with less than 1E-14 drift...).
> 
> The tracking algorithm needs some thought.  The phase detctor needs some 
> thought.  The reasons to stop tracking needs a lot of though.  The 
> reasons to start tracking again also needs thought.

> Depending on how you implement your loop, there is a patent on the way I 
> did it (uspto.gov, search on - Austin, Lesea, as inventor, and look for 

Maybe a ASSP is an easier solution. Zarlink (formerly Mitel) & Co are 
your friends.
Plug & Play.

MFG
Falk

Article: 99807
Subject: Re: OPB monitor error
From: "Guru" <ales.gorkic@email.si>
Date: 29 Mar 2006 09:50:01 -0800
Links: << >>  << T >>  << A >>
Hi Dumak,

Zara was right (thank you :)).
I found .cdc file at the "implementation\chipscope_opb_iba_0_wrapper".
It helps a lot.

Thnx,

Guru


Article: 99808
Subject: Re: Multithreaded NIOS II or other embedded cores
From: "Shyam" <shyam.thoziyoor@gmail.com>
Date: 29 Mar 2006 09:50:29 -0800
Links: << >>  << T >>  << A >>
Thanks Derek. Yeah, I haven't come across a multithreaded version of
the NIOS II so far. I was curious to know if a multithreaded NIOS is
under development. Since NIOS is an Altera core, I think a
multithreaded NIOS might be designed bottom-up more appropriately for
an FPGA implementation compared to other multithreaded cores. Will
check out  the niosforum website and see if I can find any additional
information there.

Yeah, I have also been looking at the OpenSPARC. Looks promising.
Haven't managed to synthesize it yet because our DC environment here is
not appropriately set up. I think some implementation decisions would
probably have to be different for an efficient FPGA mapping. Also guess
some of the Verilog would have to be modified in order to take
advantage of the available FPGA architecture.

Thanks again,
Shyam


Derek Simmons wrote:
> I can't speak for Altera but I haven't heard anything about a
> multithreaded/hyperthreaded NIOS core. It might be better if you asked
> you question at the www.niosforum.com website.
>
> Have you check Sun's website for the OpenSPARC project? I think it
> supports multiple cores and hyperthreading.
>
> Technology-wise it might still might be a little early to find a lot of
> projects or examples. 
> 
> Derek


Article: 99809
Subject: Re: problem with IO in EDK 8.1
From: "Guru" <ales.gorkic@email.si>
Date: 29 Mar 2006 10:05:31 -0800
Links: << >>  << T >>  << A >>
Hi Michiel,

To correctly use a tristate you need 3 ports in your peripheral design
(VHDL)
for a single port ("port") in MPD and UCF file:
port_I    port Input
port_O  port Output
port_T   port Toggle (low (0) enables you to write to tristate)

and in MPD: PORT port = "", DIR = INOUT, ENABLE=SINGLE,
THREE_STATE=TRUE

in UCF: NET port LOC = xx;

I hope this helps.

Guru


Article: 99810
Subject: Re: Stratum4E holdover
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 29 Mar 2006 10:11:31 -0800
Links: << >>  << T >>  << A >>
Falk,

Very good point!

Also check out ICS.

Austin

Falk Brunner wrote:

> Austin Lesea schrieb:
> 
> 
>> take a 20.000 MHz oscillator and generate exactly the 8 MHz reference 
>> you need.  I used for the 2E clocks, the raw rubidium output, which 
>> was 50.2037(etc) MHz (basically every rubidium is shlightly different, 
>> but they don't drift very much <1E-12, and some don't drift at all! - 
>> tested them for 8 months with less than 1E-14 drift...).
>>
>> The tracking algorithm needs some thought.  The phase detctor needs 
>> some thought.  The reasons to stop tracking needs a lot of though.  
>> The reasons to start tracking again also needs thought.
> 
> 
>> Depending on how you implement your loop, there is a patent on the way 
>> I did it (uspto.gov, search on - Austin, Lesea, as inventor, and look for 
> 
> 
> Maybe a ASSP is an easier solution. Zarlink (formerly Mitel) & Co are 
> your friends.
> Plug & Play.
> 
> MFG
> Falk

Article: 99811
Subject: Re: OpenSPARC released
From: "J o h n _ E a t o n (at) hp . com (no spaces)" <"J o h n _ E a t o n (at) hp . com (no spaces)">
Date: Wed, 29 Mar 2006 10:15:15 -0800
Links: << >>  << T >>  << A >>
Art Stamness wrote:
>>Again, I don't see how writing always blocks is "unmaintainable." Maybe I haven't had enough experience
> 
> 
> Let met explain then. Here is the "proper RTL" as some other might
> right it :
> 
> wire [31:0] a ;
> wire [31:0] b ;
> reg [32:0] result ;
> always @(posedge clk) result <= a + b ;
> 
> Here is what you will find in many high end synthesizable RTL coding
> standard examples :
> 
> wire[31:0] a ;
> wire[31:0] b ;
> wire[32:0] a_plus_b ;
> 
> assign a_plus_b = a + b ;
> 
> my_dff #(33) a_plus_b_32_0 ( .out( result ), .clk(clk), .in(a_plus_b) )
> ;
> 
>

And here is what we use in our coding standard

wire [31:0] a;
wire [31:0] b;
reg  [32:0] result;
reg  [32:0] next_result;

always@(*)
   begin
   next_result = a + b ;
   end


always@(posedge clk)
   result[32:0] <= next_result[32:0];


This seperates the sequential from the combinational logic without impacting the ability
to understand the function. Plus it can be processed so we can do things like switch
between sync and async resets or add a clock enable signal to all flops.


Hand crafting rtl code is going the way of schematic capture. Yes, it gives you complete
control of every last detail in your design but chips have grown to the point where you
don't have the time to deal with all that detail in a normal product cycle. You have to
use more automated methodogies if you plan on finishing in a reasonable time.


John Eaton









Article: 99812
Subject: Re: Stratum4E holdover
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 29 Mar 2006 10:15:55 -0800
Links: << >>  << T >>  << A >>
and,

IDT also has products.

Hard to beat when it is all done for you, and costs only ~$20 for the ASSP.

Austin

Austin Lesea wrote:

> Falk,
> 
> Very good point!
> 
> Also check out ICS.
> 
> Austin
> 
> Falk Brunner wrote:
> 
>> Austin Lesea schrieb:
>>
>>
>>> take a 20.000 MHz oscillator and generate exactly the 8 MHz reference 
>>> you need.  I used for the 2E clocks, the raw rubidium output, which 
>>> was 50.2037(etc) MHz (basically every rubidium is shlightly 
>>> different, but they don't drift very much <1E-12, and some don't 
>>> drift at all! - tested them for 8 months with less than 1E-14 drift...).
>>>
>>> The tracking algorithm needs some thought.  The phase detctor needs 
>>> some thought.  The reasons to stop tracking needs a lot of though.  
>>> The reasons to start tracking again also needs thought.
>>
>>
>>
>>> Depending on how you implement your loop, there is a patent on the 
>>> way I did it (uspto.gov, search on - Austin, Lesea, as inventor, and 
>>> look for 
>>
>>
>>
>> Maybe a ASSP is an easier solution. Zarlink (formerly Mitel) & Co are 
>> your friends.
>> Plug & Play.
>>
>> MFG
>> Falk

Article: 99813
Subject: Re: Stratum4E holdover
From: oen_no_spam@yahoo.com.br
Date: 29 Mar 2006 10:47:54 -0800
Links: << >>  << T >>  << A >>
Falk,
I know the Zarlink parts, but I already have the FPGA for other
functions. So I want to use it. Thanks anyway.

Austin,
First, thankyou very much.

I was looking "Frequency Synthesis" by Austin Lesea (what a
coincidence, do You know him?) at Xcell 31.
I didn't understand how can I have a jitter reduction, synthetising a
higher frequency and then, dividing it down. The jitter will be the
period of the incoming clock, isn't it?
Now, let's say I have a 50MHz very stable clock. Using DDFS, I generate
a 8.192MHz clock. The size of the adder (number of bits) will be
related to the precision desired, but will not be related to the
jitter. The jitter, will be 20ns (1/50MHz).
To get a better jitter I can:
a) use one DCM at the input clock to generate a higher input clock
(N*50MHz),
b) use one DCM (the DLL part) at the output clock to filter it (I'm not
sure about this).

Can you comment on this?

Luiz Carlos


Article: 99814
Subject: Re: OpenSPARC released
From: "JJ" <johnjakson@gmail.com>
Date: 29 Mar 2006 11:46:26 -0800
Links: << >>  << T >>  << A >>
Precisely, anyone who has done FPGA cpu design knows how limiting FPGAs
can be .ie 20-120MHz is typical for unfriendly architectures.

If your not in that very small club of Intel, AMD, IBM, then even full
custom is also pretty limiting by the extreme expense of it all. The
top tier may still be directly instantiating transistors as well as
flops. But then transistor level design is still able to significantly
outperform standard cell logic using a variety of mostly nmos
differential techniques, I guess by a factor of 3. At Suns level, they
are much closer to full standard cell with synthesis with a fraction of
the clock of P4s but they make up for it by going to massive threading
and latency hiding to bring out the throughput.

Theres the clue there. The same can be done in FPGA cpu for
multithreading architecture to simplify the design so that you are not
limited to 32b carry ripples. In my Transputer design I was seeing
300MHz on the PEs because it could use 2 clocks per basic opcode and
used 8 clocks for 4 thread instructions, alot of cycle limiting logic
just vanishes, ie no hazard logic or register forwarding paths. The
hardware design of the MMU hasn't started so there is nothing to
release.

For information, my PE used 500 LUTs & 1 BlockRam and a few hundred LOC
in RTL Verilog. Given V4 can hold upto 554 BlockRams, means I coudl
instance quite a few of these PEs too. In some ways it is quite similar
similar to the Niagara/Sparc, whats the difference between slidy
register files with stack spilling v register files in memory but
cached on demand (process swapped) into register caches as the T9000
did.

If I wanted to see a Niagara core in FPGA I think I would go back to
the Sparc architecture documents and maybe LEON and see if a threaded
design could be done from scratch that executes the ISA but possibly
make some very different choices so the FPGA version wouldn't get
crippled. I wouldn't be constrained to 1 opcode per clock either, using
more clocks, lowers PE performance by clock but allows a much faster
clock and much less logic so more PE cores.

I am surprised that we haven't seen alot more native FPGA MTA designs
though,.

John Jakson
Transputer guy


Article: 99815
Subject: Re: Stratum4E holdover
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 29 Mar 2006 12:03:00 -0800
Links: << >>  << T >>  << A >>
Sure,

The 20 ns will be there (in your example) and the only way to remove it 
is to filter it out.

Filters come in two forms:  a PLL, and also one can use a LC tank (with 
a Q>100).

The LC tank is very analog, but works great.  It is what I used:  MSB of 
DDFS into a 100K resistor into the LC tank, followed by a fast 
comparator.  Residual jitter was less than 1% from 10 Hz up.

A PLL with a long time constant is also very good.  I made them with 
VCXO's, an RC network to the voltage control, and a XOR phase detector.

Austin

oen_no_spam@yahoo.com.br wrote:

> Falk,
> I know the Zarlink parts, but I already have the FPGA for other
> functions. So I want to use it. Thanks anyway.
> 
> Austin,
> First, thankyou very much.
> 
> I was looking "Frequency Synthesis" by Austin Lesea (what a
> coincidence, do You know him?) at Xcell 31.
> I didn't understand how can I have a jitter reduction, synthetising a
> higher frequency and then, dividing it down. The jitter will be the
> period of the incoming clock, isn't it?
> Now, let's say I have a 50MHz very stable clock. Using DDFS, I generate
> a 8.192MHz clock. The size of the adder (number of bits) will be
> related to the precision desired, but will not be related to the
> jitter. The jitter, will be 20ns (1/50MHz).
> To get a better jitter I can:
> a) use one DCM at the input clock to generate a higher input clock
> (N*50MHz),
> b) use one DCM (the DLL part) at the output clock to filter it (I'm not
> sure about this).
> 
> Can you comment on this?
> 
> Luiz Carlos
> 

Article: 99816
Subject: Re: OpenSPARC released
From: "Art Stamness" <artstamness@gmail.com>
Date: 29 Mar 2006 12:06:07 -0800
Links: << >>  << T >>  << A >>
I would have to disagree about hand crafted code going away.

I believe Intel, IBM, Sun, AMD, Cisco, and even HP, all still use RTL
based hand coded design methodologies for most all of their designs,
that I am aware of.

IP reusage models cut down on the actual number of lines of code
written by leveraging pre-built high level libraries, with fifo's,
memories, register files, and other constructs. Soc vendors are also
doing less and less design, as more of the code they actually produce
comes in the form of pre-verified IP, and their job is moved to
verification of the integrated system from verification of the
individual components.

I don't see however "whats next", as far as getting us away from hand
written code. We can save time by buying others hand written code, but
what other tools are you aware of that would take the place of Verilog
??

-Art


Article: 99817
Subject: Re: problem with IO in EDK 8.1
From: "Mich" <michiel.vanderlinden@gmail.com>
Date: 29 Mar 2006 12:32:03 -0800
Links: << >>  << T >>  << A >>
Hi

I have test it and got this error
ERROR:MDT - test_I (IO_0) - D:\Thesis\Test\XPS_versie8\IO\system.mhs
line 358 -
   port is driven by a sourceless connector

this is what I have done
first I added this in the vhdl
test_I : in std_logic_vector (7 downto 0);
test_O : out std_logic_vector (7 downto 0);
test_T : out std_logic_vector (7 downto 0);
and this
s_test <= test_I;
test_O <= s_test;
test_T <= "00001111";

then I have added this in the MPD file
PORT test = "", DIR = INOUT, ENABLE=SINGLE, THREE_STATE=TRUE, VEC =
[7:0]
PORT test_I = "", DIR = IN, VEC = [7:0]
PORT test_O = "", DIR = OUT, VEC = [7:0]
PORT test_T = "", DIR = OUT, VEC = [7:0]

and this in the ucf file
Net IO_0_test_pin Loc = "N6";
Net IO_0_test_pin IOSTANDARD = LVTTL;

then I get this error
ERROR:MDT - test_I (IO_0) - D:\Thesis\Test\XPS_versie8\IO\system.mhs
line 358 -
   port is driven by a sourceless connector

there must be something I missed
can you tell me what it is?

Greets
Mich


Article: 99818
Subject: Re: deglitching a clock
From: "Genome" <ilike_spam@yahoo.co.uk>
Date: Wed, 29 Mar 2006 21:12:56 GMT
Links: << >>  << T >>  << A >>

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
news:i88l229so8qheephlt41crc0v7e5ebch3r@4ax.com...
> On 29 Mar 2006 01:00:59 -0800, bill.sloman@ieee.org wrote:
>
>>
>>John Larkin wrote:
>>> On 28 Mar 2006 12:45:23 -0800, bill.sloman@ieee.org wrote:
>>>
>>>
>>> >So the Fpga to Fpga routing worked - good.
>>>
>>> That's not what we did. We designed a clock deglitcher to go inside
>>> the FPGA.
>>
>>Enough propagation delays to cover the dwell at the switching
>>threshold, and a state machine to make sure that the clock only changes
>>state once in that interval?
>
>
> We did my original #2 suggestion, a tapped delay line driven from the
> pin, driving an r-s flipflop. Set the flop if all the taps are 1s,
> clear it if all are 0s. Sort of a poor man's 1-bit FIR lowpass filter.
> The delay line is a string of eight buffers, about 10 ns overall.
>
> We'd have done Peter's circuit if we'd learned of it sooner.
>
> It's interesting that my post evoked two classes of response:
>
> 1. It can't be done, don't do it, kluge the boards (also the official
> Xilinx response!)
>
> 2. Yes, and here are my ideas on how you could do it/how I've already
> done it/interesting asides.
>
> John
>
>

'We tried that before and it didn't work'

'OK, what did you try before'

'He was very good and proved it didn't work with some maths type stuff and 
it didn't work'

'Yes, but what did he try'

'It didn't work'

'But, what was it'

'It didn't work'

'Have you got the information about it'

'Err, no, err hang on.'

Waits a while. Mouldy thing arrives.

'There you go, see doesn't work'

'OK, let me have a look'

Goes away for a bit of.....

Comes back

'So, the problem is he did it like this'

'Doesn't work'

'Yes... but if you do it like this' Spends some time explaining....

'He was very clever, see... here's the math, it doesn't work. We've tried it 
before and it doesn't work'

'OK, but if you do it like this then it will work'

'No, we've already tried it and it doesn't work'

'You've tried it the way that I'm suggesting'

'Pardon'

'This way'

'Erm, he was very clever. Look, if you take some time then you can see that 
it doesn't work... How did you answer the 'Where do you see yourself in five 
years time' question at the interviev?'

DNA




Article: 99819
Subject: Re: Stratum4E holdover
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Wed, 29 Mar 2006 23:47:25 +0200
Links: << >>  << T >>  << A >>
oen_no_spam@yahoo.com.br schrieb:
> Falk,
> I know the Zarlink parts, but I already have the FPGA for other
> functions. So I want to use it. Thanks anyway.

I see. And I know that you like the challenge. But from a economic point 
of view its a matter of part cost (Austin quoted 20 $) versus 
developlment (and verification) time. And its not done in an hour if you 
did'nt do it before and are a 100% pro in this sector.

> To get a better jitter I can:
> a) use one DCM at the input clock to generate a higher input clock
> (N*50MHz),

Yes.

> b) use one DCM (the DLL part) at the output clock to filter it (I'm not
> sure about this).

Nope.

Regards
Falk

Article: 99820
Subject: Re: deglitching a clock
From: "Fred Bartoli" <fred._canxxxel_this_bartoli@RemoveThatAlso_free.fr_AndThisToo>
Date: Thu, 30 Mar 2006 00:06:34 +0200
Links: << >>  << T >>  << A >>

"Genome" <ilike_spam@yahoo.co.uk> a écrit dans le message de
news:sLCWf.25632$Nh7.15570@newsfe4-win.ntli.net...
>
> "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in
message
> news:i88l229so8qheephlt41crc0v7e5ebch3r@4ax.com...
> > On 29 Mar 2006 01:00:59 -0800, bill.sloman@ieee.org wrote:
> >
> >>
> >>John Larkin wrote:
> >>> On 28 Mar 2006 12:45:23 -0800, bill.sloman@ieee.org wrote:
> >>>
> >>>
> >>> >So the Fpga to Fpga routing worked - good.
> >>>
> >>> That's not what we did. We designed a clock deglitcher to go inside
> >>> the FPGA.
> >>
> >>Enough propagation delays to cover the dwell at the switching
> >>threshold, and a state machine to make sure that the clock only changes
> >>state once in that interval?
> >
> >
> > We did my original #2 suggestion, a tapped delay line driven from the
> > pin, driving an r-s flipflop. Set the flop if all the taps are 1s,
> > clear it if all are 0s. Sort of a poor man's 1-bit FIR lowpass filter.
> > The delay line is a string of eight buffers, about 10 ns overall.
> >
> > We'd have done Peter's circuit if we'd learned of it sooner.
> >
> > It's interesting that my post evoked two classes of response:
> >
> > 1. It can't be done, don't do it, kluge the boards (also the official
> > Xilinx response!)
> >
> > 2. Yes, and here are my ideas on how you could do it/how I've already
> > done it/interesting asides.
> >
> > John
> >
> >
>
> 'We tried that before and it didn't work'
>
> 'OK, what did you try before'
>
> 'He was very good and proved it didn't work with some maths type stuff and
> it didn't work'
>
> 'Yes, but what did he try'
>
> 'It didn't work'
>
> 'But, what was it'
>
> 'It didn't work'
>
> 'Have you got the information about it'
>
> 'Err, no, err hang on.'
>
> Waits a while. Mouldy thing arrives.
>
> 'There you go, see doesn't work'
>
> 'OK, let me have a look'
>
> Goes away for a bit of.....
>
> Comes back
>
> 'So, the problem is he did it like this'
>
> 'Doesn't work'
>
> 'Yes... but if you do it like this' Spends some time explaining....
>
> 'He was very clever, see... here's the math, it doesn't work. We've tried
it
> before and it doesn't work'
>
> 'OK, but if you do it like this then it will work'
>
> 'No, we've already tried it and it doesn't work'
>
> 'You've tried it the way that I'm suggesting'
>
> 'Pardon'
>
> 'This way'
>
> 'Erm, he was very clever. Look, if you take some time then you can see
that
> it doesn't work... How did you answer the 'Where do you see yourself in
five
> years time' question at the interviev?'
>

ROFL.


- OK, but I don't understand why it can't work. Please let me try and learn
by myself why it can't.
...
...
- Oh, but you made it work. How can it be?
- Oh. That's pretty simple: I just didn't know it couldn't work :-)

-- 
Thanks,
Fred.



Article: 99821
Subject: Re: deglitching a clock
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Thu, 30 Mar 2006 00:07:26 +0200
Links: << >>  << T >>  << A >>
Fred Bartoli schrieb:

> ROFL.

Yep. But try better quoting.

> 
> - OK, but I don't understand why it can't work. Please let me try and learn
> by myself why it can't.
> ...
> ...
> - Oh, but you made it work. How can it be?
> - Oh. That's pretty simple: I just didn't know it couldn't work :-)

I just saw a nice TV show, which ended with the words.

Theory is the thing you can't understand.
Practice is the thing you can't explain.

Regards
Falk

Article: 99822
Subject: Re: FSL to VHDL interface
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Thu, 30 Mar 2006 09:53:01 +1000
Links: << >>  << T >>  << A >>
Hi Dale,

dale.prather@gmail.com wrote:

> I'm having great difficulty interfacing my FSL to my external (from
> microblaze point of view) VHDL.  I want an FSL to communicate between
> Microblaze and my external VHDL.  I want to be able to import the .xmp
> file to my ISE project and then create the instantiation template
> (wrapper) for the XMP file (*_stub.vhd).  In the file I need to see the
> FSL control signals, data etc.  I cannot get this to happen.  I'm
> thinking there needs to be some kind of interface VHDL inside of the
> EDK project and then make those signals external.  Please offer any
> help you can.  I'm frustrated.... at the end of my rope :).

You'll probably need to create explicit FSL signals and bring these out
as toplevel ports in the EDK / MicroBlaze design.

And at the top of the MHS file, you'll have typical port declarations

PORT FSL0_S_CLK = fsl0_s_clk, DIR = O
PORT FSL0_S_DATA = fsl0_s_data, DIR = I
PORT FSL0_S_CONTROL = fsl0_s_control, DIR = I
PORT FSL0_S_EXISTS = fsl0_s_exists, DIR = I
PORT FSL0_S_READ = fsl0_s_read, DIR =O

then later


begin microblaze
...
  PARAMETER C_FSL_LINKS=1
...
  PORT FSL0_S_CLK = fsl0_s_clk
  PORT FSL0_S_DATA = fsl0_s_data
  PORT FSL0_S_CONTROL = fsl0_s_control
  PORT FSL0_S_EXISTS = fsl0_s_exists
  PORT FSL0_S_READ = fsl0_s_read
...
end

This is for a microblaze slave (incoming) port, it will be a little
different for outgoing ports, but the idea should be the same.

Does that hlep
?

John

Article: 99823
Subject: Re: OpenSPARC released
From: "J o h n _ E a t o n (at) hp . com (no spaces)" <"J o h n _ E a t o n (at) hp . com (no spaces)">
Date: Wed, 29 Mar 2006 16:07:57 -0800
Links: << >>  << T >>  << A >>
Art Stamness wrote:
> I would have to disagree about hand crafted code going away.
> 
> I believe Intel, IBM, Sun, AMD, Cisco, and even HP, all still use RTL
> based hand coded design methodologies for most all of their designs,
> that I am aware of.

Yes there is a lot of legacy code out there and a lot of design houses
are still hand coding more. They are also finding it harder and harder
to support this code as chips grow and processes shrink. You start finding
teams that are afraid to touch blocks that have been proven in silicon
for fear of introducing bugs. One of our standard practices is to
put in a new component but leave in the old version and give firmware
the ability to select which one is used at run time.

> 
> IP reusage models cut down on the actual number of lines of code
> written by leveraging pre-built high level libraries, with fifo's,
> memories, register files, and other constructs. Soc vendors are also
> doing less and less design, as more of the code they actually produce
> comes in the form of pre-verified IP, and their job is moved to
> verification of the integrated system from verification of the
> individual components.
> 
> I don't see however "whats next", as far as getting us away from hand
> written code. We can save time by buying others hand written code, but
> what other tools are you aware of that would take the place of Verilog
> ??
> 

Creating the design is 20% of the effort. Verification is the other 80%.
The industry is heading toward systems where you can specify the desired
behaviour and create the design and the testbench at the same time from the
same source. This goes well beyond providing a richer assortment of register
files. We are advancing from "assemblers" into "compilers"

But thats only the start. You want to design a component once and reuse it
over and over again. Each user should be able to reconfigure your component's
parameters for their exact needs and your tool set must be able to rebuild
both the rtl code and the testbench for these new parameters.

Futhermore the user will want to use this newly configured component as a
building block of another component in their chip. The tool set must be able
to "Plug&Play" the rtl code into the chip. This also involves building a chip
level testbench and documentation from all of the included components in a
fast and efficient manner.

Each stage should be able to verify that everything below it still works and
you can't spend weeks of engineering time fixing sims and hand placing components
to reach that point. The methodologies must be able to handle it.


John Eaton


















> -Art
> 

Article: 99824
Subject: =?iso-8859-1?q?how_to_read_this_book=AB_Digital_integrated_circuits.a_design_perspective(Second_Edition)=BB?=
From: mynewlifever@yahoo.com.cn
Date: 29 Mar 2006 16:45:32 -0800
Links: << >>  << T >>  << A >>
=ABDigital integrated circuits.a design perspective(Second
Edition)=BB
  Author:Jan.M.Rabaey

     My teach tell me this is a very good book.But now,I am a fresh
person in this field.My mostly work is write verilog code everyday.And
before I studying verilog,micron-electronic is not my major.When I was
a undergraduate student,my major is Elecronic and Infmation
Engneer.So,now,read this book is very hard for me.I also puzzled about
the relation ship between this book and RTL design.
     Please help me,thanks!




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