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 62775

Article: 62775
Subject: Re: Shannon Entropy for Black Holes
From: "John Smith" <someone@microsoft.com>
Date: Fri, 7 Nov 2003 08:56:29 -0000
Links: << >>  << T >>  << A >>

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3FAB4DAA.28A58C19@yahoo.com...
> Austin Lesea wrote:
> >
> > John,
> >
> > Nope.  1st law says that energy is conserved.  Can not lose it.
> >
> > Austin
> >
> > John Smith wrote:
> > >
> > > Aggghhhh.... I'm gonna be on 2ndlaw.com, and its sister, I may be a
while...
> > >
> > > Thanks for the answers guys. 'Lost' energy (non-recoverable energy) is
my
> > > summary. Correct?
> > >
> > > Thanks again
> > > JS
>
> John,
>
> Don't let this confuse you.  In reality "lost" energy is still energy.
> But it is lost in the sense that you can't do anything useful with it.
> It becomes spread out evenly as heat otherwise known as "disorder".
> Only "orderly" forms of energy can be used.
>
> Heat is only useful (orderly) if there is more of it here than there,
> then you can get some useful work from it by tapping it as it flows from
> here to there.  But then both here and there are at the same temperature
> and you can do no more work with that energy.  In that sense, it is
> "lost".
>
> -- 
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

Rick

I did get the drift of it, hopefully the previous poster hadn't had his
morning coffee yet.

Thanks
JS



Article: 62776
Subject: Re: Shannon Entropy for Black Holes
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Fri, 7 Nov 2003 09:09:37 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga rickman <spamgoeshere4@yahoo.com> wrote:

: Don't let this confuse you.  In reality "lost" energy is still energy. 
: But it is lost in the sense that you can't do anything useful with it. 
: It becomes spread out evenly as heat otherwise known as "disorder". 
: Only "orderly" forms of energy can be used.  

Energy: Total
Exergy: Usable part of total energy
Anergy: Unusable part of total energy

: Heat is only useful (orderly) if there is more of it here than there,
: then you can get some useful work from it by tapping it as it flows from
: here to there.  But then both here and there are at the same temperature
: and you can do no more work with that energy.  In that sense, it is
: "lost".  

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 62777
Subject: Re: Building the 'uber processor'
From: Goran Bilski <goran@xilinx.com>
Date: Fri, 07 Nov 2003 10:14:35 +0100
Links: << >>  << T >>  << A >>


Hi John,

The new instruction in MicroBlaze for handling these locallinks are 
simple but there is no HW scheduler in MicroBlaze. I have done processor 
before with complete Ada RTOS in HW but it would be an overkill in a FPGA:

The Locallinks for MicroBlaze is 32-bit wide so they are not serial.
They can handle a new word every clock cycle.

<rand mode on>

MicroBlaze has 8 new instructions for handling the Locallinks (or I call 
them FSL)
FSL = Fast Simplex Links
The are mainly two instruction with each four options.
The instruction for reading from a FSL is called GET
GET rD, FSL #n
This will get a word from the FSL number #n and move the data into 
register rD
The instruction for writing a value to a FSL is
PUT rA, FSL #n
This will move the value in register rA to FSL #n

Each FSL has a FIFO which will control if there is available data on the 
FSL or if the FSL is full.
If you try to do a GET when the FSL is empty, MicroBlaze will stall 
until the data is there and
if you try to do a PUT on a FSL which is full, MicroBlaze will stall 
until space is available on the FSL.

So the normal GET and PUT is blocking which is great when you 
communicate with HW since there is no "read status bits, mask status 
bits, branch back if not ready" loop which will reduce any kind of 
bandwidth with HW. HW tends to be much faster than SW so in general the 
blocking instruction will never block.

One option on the instruction is to have a nonblocking version of GET 
and PUT which are called nGET and nPUT.
These will try to perform the instruction and the carry bit will be set 
if they were successful and it will be cleared if they failed. This will 
make it possible to try communication on the FSL.

The FSL also have a extra bit which is done for sending more than 32-bit 
data, you can consider this as a tag information. We call it "control".
Normal PUT will set this signal to '0' but the cPUT will set it to '1'.
The Control signal is stored as the data in the FIFO so the FIFO's are 
really 33 bit.
This extra bit permits more synchronization and control/data flow 
betwene to FSL units.

The normal usage of FSL is to analyze your c-code and find a function 
where the MicroBlaze spends most of the cycles. Moce this function in 
the HW (there are getting moreand more  C-to-HW tools).
Create a wrapper in C with the same function name as the HW function. 
This wrapper will just take all the parameter and PUT them onto a FSL 
and then it's do a GET.

You could also connect up a massive array of MicroBlaze over FSL ala 
transputer but I think that the usage of the FPGA logic as SW 
accelarators will be a more popular way since FPGA logic can be many 
magnitudes faster than any processor and with the ease of interconnect 
as the FSL provides it will be the most used case.

<rant mode off>

Göran

john jakson wrote:

>Goran Bilski <goran@xilinx.com> wrote in message news:<bocq73$bgh1@cliff.xsj.xilinx.com>...
>  
>
>>Hi,
>>
>>I have been following this thread with great interest.
>>
>>If you need a processor with links to/from the processor register file 
>>then MicroBlaze could be the answer.
>>
>>MicroBlaze has 18 direct links (in the current version, the ISA allows 
>>up to 2048) and 8 new instructions for sending
>>or receiving data to/from the register file.
>>
>>The connection is called LocalLink (or FSL) and has this features
>>- Unshared non-arbitrated communication
>>- Control and Data support
>>- Uni-directional point-to-point
>>- FIFO based
>>- 600 MHz standalone operation
>>
>>    
>>
>-
>
>Hi Goran
>
>What I am really after is a speedy Transputer, better still many of
>them distributed inside & across FPGAs. Not the original with funny
>8bit opcodes (partly my fault) but a modern design that is RISC &
>targeted to FPGA using MicroBlaze as a HW/performance reference. I
>would budget for about 2x the cost before thinking of FPU, still
>pretty cheap.
>
>The important part is the ISA supports process communication
>transparently with scheduler in HW. The physical links internal or
>external is only a part of it. Since many cpus now have these links,
>and serial speeds can be far in excess of cycle speed, thats nice, but
>no use if the programmer has to program them themselves. With an
>improved event wheel scheduler in HW too, HW simulation becomes
>possible for HW that might be "hard" or "soft", but then HW in FPGAs
>are not strictly "hardware" either (see old thread). So if HW & SW can
>be somewhat interchanged, it becomes easier to migrate large C seq
>problems gradually into C-Occam par/seq then into more HDL par all
>from inside one (maybe ugly)language. It would be even nicer to start
>over with a new leaner language that can cover HDL & SW but its more
>practical to fuse together the languages people actually use.
>
>Who is the potential customer for this, any SW-HW person interested in
>speeding up SW like the original poster or any embedded engineer that
>wants to customize cpu with own HW addons using Occam style channels
>to link them. I could go on, but much work to do.
>
>
>John
>
>johnjaksonATusaDOTcom
>  
>




Article: 62778
Subject: Re: ASIC speed
From: jon@beniston.com (Jon Beniston)
Date: 7 Nov 2003 01:40:11 -0800
Links: << >>  << T >>  << A >>
> Now my question is: Is the ASIC speed result reliable? 

If it's from DC, then no.

Since we didn't
> do P&R( we don't have tools and experiences ), I really doubt the
> timing report may be over optimistically estimated and not reliable. I
> was told something about "wire load model" and ours is automatically
> selected by the compiler.

Knock off 20%, as you're likely to have a more realistic figure.

If you're working at .13, you probably want to be using physical
synthesis rather than synthesis based on wire load models.

Jon

Article: 62779
Subject: Re: Announcement
From: jon@beniston.com (Jon Beniston)
Date: 7 Nov 2003 01:48:06 -0800
Links: << >>  << T >>  << A >>
"Andras Tantos" <andras_tantos@tantos.yahoo.com> wrote in message news:<3fa942a5@news.microsoft.com>...
> > I will write a open source arm vhdl model from
> > this  month on. I hope to have it ready in
> > approximately 2 months using LeonSoc as a framework
> > and implementing a arm1 integerunit. Anyone that wants
> > to participate is wellcome.
> > Konrad Eisele
> 
> Many tried, all got kicked in the back by ARM. If you can create something
> useful, get ready for a contact from one of their lawyers,

I wrote my own clone earlier this year (just haven't got around to
releasing it yet). I spent quite a bit of time studying the patent
issues, and believe that
you should be able to implement the basic V4 instruction set (This
doens't include Thumb). The only real hurdle is then likey to be
patent 5,386,563 which deals with the exception processing mechanism.
However, I believe this patent to be invalid, as there is a
significant amount of prior art (Search for "ARM's dubious patents" in
comp.arch).

Cheers,
JonB

Article: 62780
Subject: Re: Announcement
From: jon@beniston.com (Jon Beniston)
Date: 7 Nov 2003 01:51:56 -0800
Links: << >>  << T >>  << A >>
antti@case2000.com (Antti Lukats) wrote in message news:<80a3aea5.0311060129.38e3476a@posting.google.com>...
> "Andras Tantos" <andras_tantos@tantos.yahoo.com> wrote in message news:<3fa942a5@news.microsoft.com>...
> > > I will write a open source arm vhdl model from
> > > this  month on. I hope to have it ready in
> > > approximately 2 months using LeonSoc as a framework
> > > and implementing a arm1 integerunit. Anyone that wants
> > > to participate is wellcome.
> > > Konrad Eisele
> > 
> > Many tried, all got kicked in the back by ARM. If you can create something
> > useful, get ready for a contact from one of their lawyers,
> > 
> > Andras Tantos
> 
> why write it from scratch? the nnARM source codes can be found with google
> with no problems. the synthesis result is unfortunatly quite big fits
> barely into XC2S600E
> 
> would be nice to have smaller core though ;)
> 
> antti
> PS the ARMlayers tried to take nnARM off from public internet, but its
> still downloadable, so the layers are not doing very good job.

I'm not sure if it has been worked on since the last time I saw it,
but I don't believe the nnARM could really be used as is. Didn't it
just come with a behavioural memory interface? I also seem to remember
the pipeline being pretty shallow, meaning it isn't exactly going to
go very fast.

Cheers,
Jon

Article: 62781
Subject: Re: Announcement
From: jon@beniston.com (Jon Beniston)
Date: 7 Nov 2003 01:59:53 -0800
Links: << >>  << T >>  << A >>
> > > > I will write a open source arm vhdl model from
> > > > this  month on. I hope to have it ready in
> > > > approximately 2 months using LeonSoc as a framework
> > > > and implementing a arm1 integerunit. Anyone that wants
> > > > to participate is wellcome.
> > > > Konrad Eisele
> > > 
> > > Many tried, all got kicked in the back by ARM. If you can create something
> > > useful, get ready for a contact from one of their lawyers,
> > > 
> > > Andras Tantos
> > 
> > why write it from scratch? the nnARM source codes can be found with google
> > with no problems. the synthesis result is unfortunatly quite big fits
> > barely into XC2S600E
> > 
> > would be nice to have smaller core though ;)
> > 
> > antti
> > PS the ARMlayers tried to take nnARM off from public internet, but its
> > still downloadable, so the layers are not doing very good job.
> 
> Doesn't really matter, good enough in this case, lets any potential
> commercial user get the message loud & clear. If its a 600 target,
> thats one very expensive Arm compared to real thing. For an opensource
> cpu to be useable, it must be competitive in size, speed, power with
> commercial cpus.

And if you want to be better than the competition, don't base your
design on ARM. It has (IMHO) a huge flaw in the architecture
(shifting), that means if you want decent performance, you end up
having to add tons of extra logic.

Jon

Article: 62782
Subject: spartan 3 queries
From: anjanr@yahoo.com (Anjan)
Date: 7 Nov 2003 03:11:51 -0800
Links: << >>  << T >>  << A >>
Hi
I am designing a board using spartan3 1.5million device. I got few
questions
1. I am planning to configure the device using a host DSP. The
interface is 3.3 V and slave serial mode. I am connecting a series
resistor between the DSP dicrete & PROGB of FPGA to make it tolerant
and so for CCLK and DIN. I am pulling DONE INIT to 3.3 V for the same
reason. Am I correct i this?
2. Please suggest suitable decoupling for the power supply.
Rgd

Anjan

Article: 62783
Subject: Re: latch and shift 15 bits.
From: dgleeson-2@utvinternet.com (Denis Gleeson)
Date: 7 Nov 2003 03:33:05 -0800
Links: << >>  << T >>  << A >>
Hi Chuck
 
Many thanks for your input on my question.
I have used your code and it leaves me with just one problem in my
simulator that you may be able to advise me on.
 
It is a warning that Net "/clear" does not set/reset
"/".../Store_trigger_Acquisition_Count_reg<0>
all other bits for Store_trigger_Acquisition_Count get the same
warning.
 
The result is that the synthesis tool warns that no global set/reset
(GSR) net could be used in the design as there is not a unique net
that sets or resets all the sequential cells.
 
I have modified your code to include the use of the clear signal to
set Store_Trigger_Acquisition_Count
to 0. This has had no effect. 
 
Any suggestions?
 
always @ (ACB_Decade_Count_Enable or OUT_Acquisition_Count or clear)
   if(clear) 
         Store_Trigger_Acquisition_Count <= 14'b0;
   else   
    begin
      if(ACB_Decade_Count_Enable)  // event happened input is high.
           Store_Trigger_Acquisition_Count <= OUT_Acquisition_Count;
    end

always @ (posedge clear or posedge ACB_Read_Trigger_Address_Clk )
    begin
   if(clear)
      out_count <= 4'b1110;
   else
      out_count <= out_count - 1;
end

 
Many thanks for your input.
 
Denis
"Chuck Levin" <clevin1234@comcast.net> wrote in message news:<u-udnRdzu_xrzDeiRVn-ug@comcast.com>...
> The problem is that you have assigned signal Store_Trigger_Acquisition_Count
> in two processes.
> One possible solution is the following ;
> 
> always @ (ACB_Decade_Count_Enable or OUT_Acquisition_Count)
>     begin
>       if(ACB_Decade_Count_Enable)  // event happened input is high.
>            Store_Trigger_Acquisition_Count <= OUT_Acquisition_Count;
>     end
> 
> always @ (posedge clear or posedge ACB_Read_Trigger_Address_Clk )
>     begin
>    if(clear)
>       out_count <= 4'b1110;
>    else
>       out_count <= out_count - 1;
>  end
> 
> assign ACB_Trigger_Address_Output =
> Store_Trigger_Acquisition_Count[out_count];
> 
> 
> This solution creates a latch for Store_Trigger_Acquisition_Count and then
> uses an internal down counter to mux the Output under control of the clock.
> 
> 
> "Denis Gleeson" <dgleeson-2@utvinternet.com> wrote in message
> news:184c35f9.0311060253.19553d1f@posting.google.com...
> > Hello all
> >
> > I am trying to implement the following logic in a xilinx XCS05xl
> > FPGA.
> >
> > I have a 15 bit binary counter. I need to store its count value
> > on the occurrence  of an event. Some time later I need to shift the stored
> > counter value out of the FPGA in a serial fashion under the control
> > of a clock.
> >
> > What I currently have is:
> > -----------------------------------------------------------------------
> > input clear;
> > reg clear;
> >
> > input ACB_Decade_Count_Enable;
> >
> > input ACB_Read_Trigger_Address_Clk;
> >
> > output ACB_Trigger_Address_Output;
> > reg ACB_Trigger_Address_Output;
> >
> > reg [14:0] Store_Trigger_Acquisition_Count; // Storage for counter count.
> >
> >
> > // Store the count value when ACB_Decade_Count_Enable is high.
> > always @ (ACB_Decade_Count_Enable)
> >     begin
> >       if(ACB_Decade_Count_Enable)  // event happened input is high.
> > Store_Trigger_Acquisition_Count <= OUT_Acquisition_Count;
> >     end
> >
> > // Now shift out the stored count serially.
> > always @ (posedge clear or posedge ACB_Read_Trigger_Address_Clk)
> >    begin
> > if(clear)
> >   begin
> > ACB_Trigger_Address_Output <=0;
> >   end
> > else
> >     begin
> >     ACB_Trigger_Address_Output <=Store_Trigger_Acquisition_Count[14];
> > Store_Trigger_Acquisition_Count <= Store_Trigger_Acquisition_Count << 1;
> >   end
> >    end
> >
> > -----------------------------------------------------------------------
> >
> > With this code my synthesis step gives the following errors.
> >
> > Warning - Latch inferred in design "My block" read with
> >           'hdlin_check_no_latch'(HDL - 307)
> >
> > Error   - The net /../my block/Store_Trigger_Acquisition_Count<13> has
>  more
> >           than one driver(FPGA-CHECK-5)
> >
> > The last error is repeated for all bits in
>  Store_Trigger_Acquisition_Count.
> >
> >
> > The logic above seems correct in my head but Im not an FPGA expert.
> > Obviously I need a different implementation. Any suggestions.
> >
> >
> > Many thanks for all suggestions in advance.
> >
> > Denis

Article: 62784
Subject: FPGA & handling reset of a logic block while running
From: se10110@yahoo.com
Date: 7 Nov 2003 03:57:05 -0800
Links: << >>  << T >>  << A >>
Hello,

In a current FPGA-based design, I have a sub-block whose synchronous
outputs  drive some logic such as counters & flip-flops(external to
the sub-block but internal to the FPGA). The current design has the
sub-block synchronously enabled when it needs to be used and
synchronously disabled when it does not need to be used.

When the block is de-selected (going from enabled to disabled), I
would like the sub-block's flip-flops to be reset, so the next time
the block is enabled, the outputs are in a known state.

My question: 

Is it safe to use a synchronous reset signal which is high for one
system clock cycle to drive the async reset on the flip-flops of my
sub-block?

Note: The sub-block flip-flops are synchronously disabled before being
reset by the synchronous reset signal, so I am not creating a
setup/hold time problem with the sub-block FFs.

My real concern is about violating the setup & hold time on the
flip-flops the sub-block drives. My thinking is that even though the
reset signal is synchronous, the sync. reset signal will probably not
be distributed via a low-skew line (aka global signal) and I could
potentially have a far sub-block flip-flop not reset by the time the
clock comes around, and thus I clober a flip-flop which is driven by a
s-b FF.

If driving the async. reset on the FFs is a bad idea, my other
approach was to take each DFF of the sub-block and update it to
include a 2-input AND gate on the input. One input to the AND2 gets
the original D-input signal while the second input gets a NOTed
SCLR(active high), so I create a synchronous clearable DFF.

I would appreciate comments, suggestions, etc.

Jay

Article: 62785
Subject: Re: Building the 'uber processor'
From: Mario Trams <Mario.Trams@informatik.tu-chemnitz.de>
Date: Fri, 07 Nov 2003 13:01:22 +0100
Links: << >>  << T >>  << A >>
john jakson wrote:

> What I am really after is a speedy Transputer, better still many of
> them distributed inside & across FPGAs. Not the original with funny
> 8bit opcodes (partly my fault) but a modern design that is RISC &
> targeted to FPGA using MicroBlaze as a HW/performance reference. I
> would budget for about 2x the cost before thinking of FPU, still
> pretty cheap.

Hi John,

do you know about this nice stuff developed by Cradle
(http://www.cradle.com) ?

They have developed something like an FPGA. But the PFUs 
do not consist of generic logic blocks but small processors.
That's perhaps something you would like :-)

Regards,
Mario



Article: 62786
Subject: Re: Crossing/muxing clocks thru TBUF mux (w/DLL "stunts")
From: Philip Freidin <philip@fliptronics.com>
Date: Fri, 07 Nov 2003 12:10:05 GMT
Links: << >>  << T >>  << A >>
On Thu, 06 Nov 2003 07:50:23 -0800, Austin Lesea <Austin.Lesea@xilinx.com> wrote:
>Morten,
>
>With the FROM:TO constraints I have always found them applying to things that
>I did not want them to.  To really get the constraint "correct" (so that it
>didn't want to apply it to something else), I had to use FROM:THROUGH:TO
>(specify the path in question).
>
>After mucking about with this for a long time, and failing to get a
>reasonable result, I just pulled the constraints, and used the period
>constraint all alone.  The multicycle through paths now did not meet timing
>(failed), but at least I could go and manually check each one, and "sign off"
>that these paths were OK none the less.

Have you filed a case with the hotline?

>The area was also massively affected by the FROM:THOUGH:TO constraints, with
>very poor timing results (worse than the period constraint alone) resulting
>on the paths that I really cared about and larger area.....

Probably should file a case on this too.

>I suppose that if I had a single clock things would have worked better, but
>with multiple clock domains, resynchonization circuits, and the rest of the
>stuff, the FROM:TO constraints just seemed to be causing me nothing but
>headaches.

Maybe file a case on this?

>(as the synthesizer just seemed to want to apply relaxed
>constraints to too many paths).

ok, I'll shut up now.


>Austin

Philip



Article: 62787
Subject: Re: Announcement
From: eiselekd@web.de (Konrad Eisele)
Date: 7 Nov 2003 04:14:51 -0800
Links: << >>  << T >>  << A >>
johnjakson@yahoo.com (john jakson) wrote in message news:<adb3971c.0311061709.5ca8cff7@posting.google.com>...
> antti@case2000.com (Antti Lukats) wrote in message news:<80a3aea5.0311060129.38e3476a@posting.google.com>...
> > "Andras Tantos" <andras_tantos@tantos.yahoo.com> wrote in message news:<3fa942a5@news.microsoft.com>...
> > > > I will write a open source arm vhdl model from
> > > > this  month on. I hope to have it ready in
> > > > approximately 2 months using LeonSoc as a framework
> > > > and implementing a arm1 integerunit. Anyone that wants
> > > > to participate is wellcome.
> > > > Konrad Eisele
> > > 
> > > Many tried, all got kicked in the back by ARM. If you can create something
> > > useful, get ready for a contact from one of their lawyers,
> > > 
> > > Andras Tantos
> > 
> > why write it from scratch? the nnARM source codes can be found with google
> > with no problems. the synthesis result is unfortunatly quite big fits
> > barely into XC2S600E
> > 
> > would be nice to have smaller core though ;)
> > 
> > antti
> > PS the ARMlayers tried to take nnARM off from public internet, but its
> > still downloadable, so the layers are not doing very good job.
> 
> Doesn't really matter, good enough in this case, lets any potential
> commercial user get the message loud & clear. If its a 600 target,
> thats one very expensive Arm compared to real thing. For an opensource
> cpu to be useable, it must be competitive in size, speed, power with
> commercial cpus.
> 
> johnjaksonATusaDOTcom

Does anyone know when the arm license is going to expire?

Article: 62788
Subject: Re: Virtex II DCM & ZBT SRAM
From: brimdavis@aol.com (Brian Davis)
Date: 7 Nov 2003 04:37:45 -0800
Links: << >>  << T >>  << A >>
I wrote:
>
> Possibly Helpful Answer Records:
> 
oops, I left off one with a good description of manual IOB timing
calculations required to correct reported DDR setup times:

18079 	 The input setup/hold requirement reported by TRCE seems
         excessive for my design; is the value correct? 

Brian

Article: 62789
Subject: Re: Programmer's unpaid overtime.
From: "Nial Stewart" <nial@spamno.nialstewart.co.uk>
Date: Fri, 7 Nov 2003 12:48:31 -0000
Links: << >>  << T >>  << A >>

Phil Hays <SpamPostmaster@attbi.com> wrote in message
news:3FAA5342.B1F91A03@attbi.com...

> The current law makes salaried people not get paid overtime.  If you don't
think
> that is fair, you need to convince voters to elect people that will change
the
> laws.

Surely all the law says is that if you sign a contract of employment
which say you don't get paid overtime, then you can't expect to get
paid for overtime?

It's up to you whether you sign in the first place.

?


Nial





Article: 62790
Subject: Re: Shannon Entropy for Black Holes
From: Jerry Avins <jya@ieee.org>
Date: Fri, 07 Nov 2003 09:50:06 -0500
Links: << >>  << T >>  << A >>
rickman wrote:

   ...

> Don't let this confuse you.  In reality "lost" energy is still energy. 
> But it is lost in the sense that you can't do anything useful with it. 
> It becomes spread out evenly as heat otherwise known as "disorder". 
> Only "orderly" forms of energy can be used.  
> 
> Heat is only useful (orderly) if there is more of it here than there,
> then you can get some useful work from it by tapping it as it flows from
> here to there.  But then both here and there are at the same temperature
> and you can do no more work with that energy.  In that sense, it is
> "lost".  

Nicely put. A corollary is that when everything is at the same
temperature, nothing can be seen. Some electric ovens have a covered
eye hole so that one can see what's happening by swinging aside the flap
and peering in. There is often enough glow from the hot walls to show
the work. The work disappears at equilibrium, when it reaches the
temperature of the walls.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ


Article: 62791
Subject: Re: Programmer's unpaid overtime.
From: "Ken Land" <kland1@neuralog1.com>
Date: Fri, 7 Nov 2003 09:40:18 -0600
Links: << >>  << T >>  << A >>
I've been a  programmer for over 15 yrs.  I'm still  a programmer and I
employ programmers in my company.

Programmer output can vary (easily) by a factor of 10 from programmer to
programmer. (This is documented BTW - see "Rapid Development")

If you are an average or above programmer and you are *actually writing
code*, your output is so incredibly high that overtime will almost always be
unecessary.  Also, average to above average programmers *love* to write code
and would work extra hours just for the enjoyment if they didn't have
families to go home to.

One more thing.  As an employer/business owner - we have no incentive or
inherent desire for people to work unpaid overtime.  We just need the work
done to keep the business moving forward.  If you can do your part in 10
hours/wk. great, if not then whatever it takes is what it takes.

Ken


"Nial Stewart" <nial@spamno.nialstewart.co.uk> wrote in message
news:3fab93a1$0$12691$fa0fcedb@lovejoy.zen.co.uk...
>
> Phil Hays <SpamPostmaster@attbi.com> wrote in message
> news:3FAA5342.B1F91A03@attbi.com...
>
> > The current law makes salaried people not get paid overtime.  If you
don't
> think
> > that is fair, you need to convince voters to elect people that will
change
> the
> > laws.
>
> Surely all the law says is that if you sign a contract of employment
> which say you don't get paid overtime, then you can't expect to get
> paid for overtime?
>
> It's up to you whether you sign in the first place.
>
> ?
>
>
> Nial
>
>
>
>



Article: 62792
Subject: Re: Impact, SVF, assumed TCK frequency?
From: Amontec Team <laurent.gauch@www.DELALLCAPSamontec.com>
Date: Fri, 07 Nov 2003 16:41:10 +0100
Links: << >>  << T >>  << A >>
Petter Gustad wrote:
> In SVF files generated by impact there will be delay statements on the
> form:
> 
>    // Loading device with a 'ferase' instruction. 
>    ...
>    RUNTEST 15000000 TCK;
> 
> What is the minimum delay as a result of this statement, i.e. what is
> the assumed TCK frequency for impact generated SVF files?
> 
> TIA
> Petter
> 
In the Xilinx SVF file, the assumed TCK is the maximum TCK frequency of 
the device. Look the datasheet of the FPGA or your CPLD (between 10 to 
40 MHz).

Laurent
www.amontec.com
__________________________________
Q01 2004 -> Amontec will introduce
a new USB JTAG POD based SVF !
==================================


Article: 62793
Subject: Re: Crossing/muxing clocks thru TBUF mux (w/DLL "stunts")
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Fri, 07 Nov 2003 07:58:49 -0800
Links: << >>  << T >>  << A >>
Philip,

Funny, and appreciated.  No, I did not file a case.  I was designing standard cell
logic.....not using DC for the FPGA.  ASIC designers have exactly the same problems,
and there is no solution in that space either.

Austin


Philip Freidin wrote:

> On Thu, 06 Nov 2003 07:50:23 -0800, Austin Lesea <Austin.Lesea@xilinx.com> wrote:
> >Morten,
> >
> >With the FROM:TO constraints I have always found them applying to things that
> >I did not want them to.  To really get the constraint "correct" (so that it
> >didn't want to apply it to something else), I had to use FROM:THROUGH:TO
> >(specify the path in question).
> >
> >After mucking about with this for a long time, and failing to get a
> >reasonable result, I just pulled the constraints, and used the period
> >constraint all alone.  The multicycle through paths now did not meet timing
> >(failed), but at least I could go and manually check each one, and "sign off"
> >that these paths were OK none the less.
>
> Have you filed a case with the hotline?
>
> >The area was also massively affected by the FROM:THOUGH:TO constraints, with
> >very poor timing results (worse than the period constraint alone) resulting
> >on the paths that I really cared about and larger area.....
>
> Probably should file a case on this too.
>
> >I suppose that if I had a single clock things would have worked better, but
> >with multiple clock domains, resynchonization circuits, and the rest of the
> >stuff, the FROM:TO constraints just seemed to be causing me nothing but
> >headaches.
>
> Maybe file a case on this?
>
> >(as the synthesizer just seemed to want to apply relaxed
> >constraints to too many paths).
>
> ok, I'll shut up now.
>
> >Austin
>
> Philip


Article: 62794
Subject: Re: Altera "my support" :-(
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Fri, 07 Nov 2003 08:07:41 -0800
Links: << >>  << T >>  << A >>
Rick,

Not true at Xilinx.  Closing a case that is unresolved with an unhappy
customer is potentially grounds for disciplinary action.

That is why I am the volunteer 'lightning rod' for such complaints.  I am not
interested in disciplining folks, but rather in improving the service that is
offered (find the problem:  fix it).

Austin

rickman wrote:

> Just remember that support people get graded on how quickly they close
> cases, not how "well" they close them (as least as far as I can tell).
> And this is not limited to Altera.  Speed is clearly the primary
> evaluation of support at most companies.
>
> Joe Thompson wrote:
> >
> > I'm in the middle of a similar situation.  I just reported a fatal,
> > reproducible error on "My Support."  Once the tech was able to
> > reproduce the error, his response was that the bug would be "fixed in
> > a future version..."  Case closed.
> >
> > He also said that he successfully tested the design using the
> > integrated FPGA Compiler II tool (I'm using Precision) and recommended
> > that approach as a workaround.  I tried it and found that my
> > utilization jumped from ~75% with Precision to 116% with the
> > integrated synthesis.
> >
> > Needless to say, I am not impressed.
> >
> > Joe
> > ------------------------------------------------------------
> > Joe G. Thompson                        Phone: (603) 512-9003
> > joe@advancedprinciples.com               Fax: (208) 730-5713
> >
> > On 3 Nov 2003 01:05:37 -0800, rotemg@mysticom.com (Rotem Gazit) wrote:
> >
> > >Recently we decided to use Altera Cyclone part in a new design. When
> > >we ran into problems I opened a web case using "Altera's my support".
> > >After two days of silence I added an update explaining why the problem
> > >is urgent.
> > >After 10 days !!! I got the first response asking for the name of the
> > >local FAE and providing no more information.
> > >I answered the question and in exchange I got email saying "your
> > >service request will be closed" .
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX


Article: 62795
Subject: Re: ASIC speed
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Fri, 07 Nov 2003 08:13:22 -0800
Links: << >>  << T >>  << A >>
Yu Jun,

Knock off 20% for .13u from schematic to RC extracted.

Also depends on what the foundry actually supports:  is this based on lo-k
dieletric?

If not, that will take you down another 5%.

The Virtex II Pro IBM405PPC runs at 450 MHz, so I would expect any well
designed and semi-custom layout uP to be at least that fast in .13u.

Austin

Yu Jun wrote:

> I'm working on a cpu core and intend to embed it into ASIC circuits,
> with the aim to do some network processing. Now the FPGA prototype is
> running and a 66M speed is achieved( xilinx virtexII-4 ). Wondering
> how fast it can run in ASIC, we had our ASIC guys to synthesize the
> codes and the result was shocking, it reached 400M! Far beyond our
> expectation of 150M. The library we used was of 0.13u, from TI, fairly
> fast, in which a NAND gate is around 0.03ns.
>
> Now my question is: Is the ASIC speed result reliable? Since we didn't
> do P&R( we don't have tools and experiences ), I really doubt the
> timing report may be over optimistically estimated and not reliable. I
> was told something about "wire load model" and ours is automatically
> selected by the compiler.
>
> Anybody can give me some hints or direct me to some documents will be
> very appreciated! Thank you very much.
>
> yu jun
>
> yujun@huawei.com


Article: 62796
Subject: Re: Arithmetics with carry
From: starbugs@gmx.net (Kevin Becker)
Date: 7 Nov 2003 08:13:25 -0800
Links: << >>  << T >>  << A >>
Francisco Rodriguez wrote:
> As your numbers are 32-bit wide, and overflow condition is a flag
> about the result of the _whole_ v := v + i operation, it can be determined
> by the MSB bits only (that is, from columns 31 and 30 of the addition).

Thank you! I think I used the wrong word "underflow". What I mean is:
if "i" is negative, it might be that abs(lo(i)) is greater than lo(v).
What happens then? An example:

v = 1234 0100 hex
i = 0000 0101 hex

The operation for the lo bits will result in FFFF and the carry will
be set. Then when I add the high bits, it will be 1235 when it should
actually be 1233. How do I save that the first operation was not an
overflow but a borrow? (I don't know how to call this. That's what I
mistakenly called underflow).

Glen Herrmannsfeld wrote:
> After the high halfword add, you compare the carry out to the carry out of
> the sign bit to the carry in of the sign bit.  If they are different then it
> is overflow or underflow.  The value of such bit tells you which one.

So does that mean I have to modify my architecture and set TWO flags?
A carry flag and a negative flag (if sign of last operation was
negative), and then the Add-With-Carry instruction would look at both?

Thanks a lot!

Article: 62797
Subject: Re: FPGA & handling reset of a logic block while running
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 07 Nov 2003 16:30:34 GMT
Links: << >>  << T >>  << A >>
Since this is the fpga newsgroup, not the ASIC folks....

Synchronous resets used directly in your design are great to use.  The
timing analysis knows when sync resets use synchronous resources.  Using a
synchronous signal to asynchronously reset is problematic but - after a few
incorrect tries - you can probably apply proper constraints to make them
work.

Some FPGAs have dedicated set/reset resources that can be either synchronous
or asynchronous.  Other FPGAs have some of their logic configurations design
to use a synchronous clear applicable in the particular configuration.

Often adding a single additional input - in the form of the synchronous
reset - keeps the logic within the LUT or LE that was originally produced.
The performance reduction due to synchronous resets can be pretty minor -
often not an issue.

- John_H


<se10110@yahoo.com> wrote in message
news:96922c52.0311070357.7493b7c4@posting.google.com...
> Hello,
>
> In a current FPGA-based design, I have a sub-block whose synchronous
> outputs  drive some logic such as counters & flip-flops(external to
> the sub-block but internal to the FPGA). The current design has the
> sub-block synchronously enabled when it needs to be used and
> synchronously disabled when it does not need to be used.
>
> When the block is de-selected (going from enabled to disabled), I
> would like the sub-block's flip-flops to be reset, so the next time
> the block is enabled, the outputs are in a known state.
>
> My question:
>
> Is it safe to use a synchronous reset signal which is high for one
> system clock cycle to drive the async reset on the flip-flops of my
> sub-block?
>
> Note: The sub-block flip-flops are synchronously disabled before being
> reset by the synchronous reset signal, so I am not creating a
> setup/hold time problem with the sub-block FFs.
>
> My real concern is about violating the setup & hold time on the
> flip-flops the sub-block drives. My thinking is that even though the
> reset signal is synchronous, the sync. reset signal will probably not
> be distributed via a low-skew line (aka global signal) and I could
> potentially have a far sub-block flip-flop not reset by the time the
> clock comes around, and thus I clober a flip-flop which is driven by a
> s-b FF.
>
> If driving the async. reset on the FFs is a bad idea, my other
> approach was to take each DFF of the sub-block and update it to
> include a 2-input AND gate on the input. One input to the AND2 gets
> the original D-input signal while the second input gets a NOTed
> SCLR(active high), so I create a synchronous clearable DFF.
>
> I would appreciate comments, suggestions, etc.
>
> Jay



Article: 62798
Subject: External Modules and FPGA Primitives
From: tom1@launchbird.com (Tom Hawkins)
Date: 7 Nov 2003 08:36:06 -0800
Links: << >>  << T >>  << A >>
Hello,

I recently release Confluence 0.7.3.  The big addition is
the ability to instantiate custom Verilog and VHDL modules
from with in Confluence.  This feature is especially
useful for instantiating FPGA specific blocks with configurable
constraints (timing, RLOC, etc.).

Both sequential and combinatorial modules are supported, and
modules may include any number of configuration parameters.
You can also create C and Python models for your external components
to integrate with Confluence generated C and Python for simulation.

Installation is easier too.  Just extract the tarball (_.tar.gz),
set an environment variable, update the path, and your done.

I also removed license protection.
Like most tool users, I hate dealing with LM.  So Confluence
is now on the honor system.  My licensing policy still stands:
free for personal and academic use, and 1 free seat per company
for commercial endeavors.  Companies can also install any number
of copies for evaluation.

Download at: http://www.launchbird.com/download.html

Confluence runs on Linux (x86), Cygwin (windows), and Solaris.


Regards,
Tom

--
Tom Hawkins
Launchbird Design Systems, Inc.
952-200-3790
http://www.launchbird.com/

Article: 62799
Subject: Re: FPGA & handling reset of a logic block while running
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 07 Nov 2003 10:20:30 -0800
Links: << >>  << T >>  << A >>
se10110@yahoo.com wrote:

> My real concern is about violating the setup & hold time on the
> flip-flops the sub-block drives. My thinking is that even though the
> reset signal is synchronous, the sync. reset signal will probably not
> be distributed via a low-skew line 

True. You wouldn't want to waste one for a single connection.

> If driving the async. reset on the FFs is a bad idea, my other
> approach was to take each DFF of the sub-block and update it to
> include a 2-input AND gate on the input. One input to the AND2 gets
> the original D-input signal while the second input gets a NOTed
> SCLR(active high), so I create a synchronous clearable DFF.

Yes. Do that.

  -- Mike Treseler




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