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 9950

Article: 9950
Subject: Xilinx RPMs for DSP (16-tap 8-bit FIR)
From: janovetz@ews.uiuc.edu (Jacob W Janovetz)
Date: 16 Apr 1998 02:09:37 GMT
Links: << >>  << T >>  << A >>
Hi...

   I'm interested in using something like the 16-tap 8-bit FIR
described in Xilinx's app note.  I'm using Leonardo for
VHDL synthesis and, perhaps I'm missing something obvious, 
but it seems that I should be able to just invoke this RPM
somehow and not do a whole lotta work.  Is my intuition 
wrong?  How do I go about doing this?  A pointer to a document
would be fine if there is one out there.

    Cheers,
    Jake

--
   janovetz@uiuc.edu    | Once you have flown, you will walk the earth with
 University of Illinois | your eyes turned skyward, for there you have been,
                        | there you long to return.     -- da Vinci
        PP-ASEL         | http://www.ews.uiuc.edu/~janovetz/index.html
Article: 9951
Subject: Re: Xilinx Timing Constraints
From: Rickman <spamgoeshere1@yahoo.com>
Date: Wed, 15 Apr 1998 23:24:29 -0400
Links: << >>  << T >>  << A >>
lnwolf@amaroq.com wrote:
> 
> Hello, I am designing towards a XC4020E device using M1.4 tools
> under both the PC and unix. I have a couple questions
> concerning the use of the period definition in timing
> constraints.
> 
> I have the following clock period settings defined:
> 
> ts01=period:ff_8m:115ns:high:%50
> ts02=period:ff_4m:ts01:*:2:low:%50
> ts03=period:ff_2m:ts02:*:2:low:%50
> 
> I have two questions concerning the above definitions:
> 
> 1. Because I have defined all three clocks in terms of each other
> will the xilinx software automatically constrain data paths
> that go from a ff_8m block to a ff_4m block? I figure this is
> too much to hope for but could eminate a few other timing constraints
> I have defined for these paths. The only reason I am lead to think that
> this may be possible is inclusion of fields that set which state a clock
> starts in. The only reason I can see for needing this information is
> to reference it to another clock.
> 
> 2. Does the xilinx software make any assumptions about data paths
> coming from pads to a block that falls into one of the above three
> constraints? What about blocks going out to pads?
> 
> Just wondering if I can eliminate a few lines of timing constraints.


This is just the type of problem that I am trying to deal with. I have
received several forms of information on how to apply timing constraints
from Xilinx. The best is a set of class handouts that were faxed to me.
In these handouts, there is a section on the multi-cycle clock problem.
This would be clocking at, say, 40 MHz, but only enabling the CE on
every other cycle. So the CE path has to run at the full 40 MHz, but the
data can take two cycles to be setup. 

Your problem is similar in that the software must recognize that when
you go between two registers clocked at multiples of one another, the
interface must run at the highest of the two rates. 

I will be getting back to my design this week. When I get to that
section of the notes, I will see if there is anything specific to your
problem. 

Rick Collins

rickman@XYwriteme.com

remove the XY to email me.
Article: 9952
Subject: Re: Synplicity
From: Rickman <spamgoeshere1@yahoo.com>
Date: Wed, 15 Apr 1998 23:31:35 -0400
Links: << >>  << T >>  << A >>
Bill Seiler wrote:
> 
> I use Synplify all the time.  We are packing 45,000 gates into a
> Xilinx 4085XL.  Synplify is very fast.   It will synthesis your whole
> design.  It maintains heirecy in the names.  The RTL View and
> Technology View are great tools to let you see the logic you code
> generated.  Synplify's timing estimates are off by a factor of 2 to 1.
> 
> A tool worth the money!
> 
> Bill Seiler

Bill,

Obviously, you are satisfied with the Synplify tool. But how do you deal
with the timing estimates being so far off? I am using the Xilinx
backend with the Orcad front end. The timing results I get from the
Xilinx back end are right on of course. 

Does the Synplify tool work through the Xilinx back end also? If not,
how do you get realistic timing data after a place and route? If it does
work with the Xilinx back end, do you find adding timing constraints to
work well? I am having a lot of trouble with the Orcad tool just in the
learning curve. So I haven't found out yet about how well it works.
Orcad with Xilinx seems to be so new that neither company quite knows
much about supporting it. 


Rick Collins

rickman@XYwriteme.com

remove the XY to email me.
Article: 9953
Subject: Re: Xilinx Timing Constraints
From: ems@see_sig.com (ems)
Date: Thu, 16 Apr 1998 07:32:46 GMT
Links: << >>  << T >>  << A >>
On Wed, 15 Apr 1998 23:24:29 -0400, Rickman <spamgoeshere1@yahoo.com>
wrote:

> The best is a set of class handouts that were faxed to me.
>In these handouts, there is a section on the multi-cycle clock problem.

any idea how i can get these? could you let us know who/where you got
them from?

thanks 

evan (ems@riverside-machines.com)
Article: 9954
Subject: Re: Xilinx Timing Constraints
From: Ed McCauley <edmccauley@bltinc.com>
Date: Thu, 16 Apr 1998 09:31:28 -0400
Links: << >>  << T >>  << A >>
I am one of the trainers that Xilinx uses at the factory and in the
field.  My company does Xilinx design work and teaches the most Xilinx
Classes on the East coast.  

You've ask two good question.  I honestly waited a bit before
responding.  I try to "Never miss an opportunity to shut up!"  Seems
like you're on the bleeding edge of TSpecs!  

First, defining one constraint in terms of another:

A. I honestly didn't know you could do that!
B. I honestly wouldn't do that!

I like to keep things REALLY strait forward on this stuff - not get cute
or fancy.  This keeps it clear to subsequent supporters of my work and
it also keeps me in the mainstream of xilinx users - where the support
is!

So on your first question, I offer an opinion not an answer: keep the
TSpecs desecrate within their domains and add additional TSpecs between
domains.  That's the way the 60/15MHz pre-scaled counter presented
during class lecture is handled.


Secondly, 

> 2. Does the xilinx software make any assumptions about data paths
> coming from pads to a block that falls into one of the above three
> constraints? What about blocks going out to pads?

The period constraint covers FFs to FFs and PADs to FFs.  FFs to PADs **
ARE NOT ** covered!  (Nether are PADs to PADs.) To address FFs to PADs,
one should use the OFFSET constraint OR the path constraint
FFS:TO:PADS.  

I'll throw in a tip here:  We try to register everything onto and off of
our dies.  This provides optimal and PREDICTABLE timing regardless of
PAR (or PPR) runs.  In a multichip design, the timing interface to the
FPGA becomes data book like - constant.

One last opinion:  MOST designs need only basic Timespecs.  Using your
example, just letting the entire chip run with a period of 115ns would
PROBABLY be just fine - as in NO problem.  IF you believe 115ns is a
challenge, I would ask you to consider the architecture of your design.

One of the Five BLT "Golden Rules" of FPGA design is: "Thow shalt
develop and remain within thine own timing budget"  That is to say, for
your clock speed and part speed, determine how many levels of
combinatorial delay you can tolerate (including matching routing delays)
and design to that number. (We actually try for one less to allow for
changes and error.) 

In your example: 115ns / 3 ('plain jane' -3 4000XL speed grade #) / 2
(to accommodate LUTs and Routes) = ~19 levels of logic - A WHOLE LOT 'O
LOGIC GOING ON!


Good luck and best wishes with your design.  As usual, these opinions
are that of Bottom Line Technologies Inc., not _necessarily_ Xilinx.

-- 
Ed McCauley
Bottom Line Technologies Inc.
Specializing Exclusively in Xilinx Design, Development and Training
Voice: (500) 447-FPGA, (908) 996-0817
FAX:   (908) 996-0817
Article: 9955
Subject: Job Opening
From: Mike Kelly <mike@cogcomp.com>
Date: Thu, 16 Apr 1998 17:44:04 -0400
Links: << >>  << T >>  << A >>
Hey all,

I apologize if this is undesired.  We have an opening for a senior
Hardware Engineer.  FPGA, VHDL, Verilog, are all pluses.  See our
web site for more detail

Thanks,

Mike

*******************************************************
* Michael J. Kelly              tel: (508) 278-9400   *
* Cogent Computer Systems, Inc. fax: (508) 278-9500   *
* 10 River Rd., Suite 205       web: www.cogcomp.com  *
* Uxbridge, MA 01569          email: mike@cogcomp.com *
*                                                     *
* CMA - Universal Target Platform for 32/64-Bit RISC  *
*******************************************************
Article: 9956
Subject: Survey of RTOS?
From: "Jon Cummings" <cflat@monumental.com>
Date: 17 Apr 1998 01:14:40 GMT
Links: << >>  << T >>  << A >>
Sure would appreciate a bit of help

It runs in my mind that one of the subscribers to one of these two
newsgroups had a survey of realtime operating systems (RTOS).  Where can I
get a copy of that survey or download that survey?

Thanks

Jon Cummings
Article: 9957
Subject: state machine
From: jkanajan@ets.cis.brown.edu (Jaya_Kanajan)
Date: 17 Apr 1998 01:45:26 GMT
Links: << >>  << T >>  << A >>
Hello,
 
I've been staring at this piece of verilog for way too long.
Hopefully, someone here can catch my bug:
 
this is some fsm code that for reasons beyond my understanding
do not work in simulation.
 
I am using the FPGA express by Synopsys as my compiler. I compile
to a Xilinx XC4000EX implementation which is then forcibly optimized
by the Synopsys FPGA express (I can't make it allow me to skip this
step). This is then exported to a netlist which is then imported
into the Xilinx Project Manager simulator for simulation.
 
In the simulator, the fsm starts up in state 0, on the first clock
it goes to the F state. Now, in both my F state and default state
and 0'th state, I define two signals, leftramCEbar and rightramCEbar
to both be high. (F state is nopstate) There is also a signal DTACK
which I define to be high as well.
 
Now, in simulation, (unfortunately), the leftramCEbar and rightramCEbar
start out low. Despite many attempts to fix this, we have failed. DTACK
on the other hand starts out well and behaves decently. both the CEbar
signals behave decently only after 6 state transitions later.
 
I attach portions of the code for your perusal. Any help would be very
extremely appreciated. It has been 4 days of about 8 hours a day work
just trying to figure out what this bug is due to. I am about to give
up and hopefully someone here can save the day.

Thanks,
jaya
 
--- Included verilog codde ---
 
`define nopSTATE     4'd15
 
`define writeSTATE   4'd14
`define wbyteSTATE   4'd13
`define wwordSTATE 4'd12
`define leftwriteSTATE 4'd11
`define rightwriteSTATE 4'd10
`define donewriteSTATE 4'd9
`define wreleaseSTATE 4'd8
 
`define readSTATE    4'd7
`define rbyteSTATE   4'd6
`define rwordSTATE 4'd5
`define leftreadSTATE 4'd4
`define rightreadSTATE 4'd3
`define donereadSTATE 4'd2
`define rreleaseSTATE 4'd1
`define zeroSTATE       4'd0
 
 
 
// synopsys async_set_reset "reset"
/* synopsys async_set_reset_local infer1 "state, validaddr"*/
   always @ (posedge clk or negedge reset)
      begin : infer1
if (!reset)
    begin
       state <= 0;
       //
       validaddr = 0;
    end
else
           begin
       state <= next_state;
       //         addr_out <= addressbits;
       // data_out <= data_in;
       if ((addressbits[12] == 1) && (addressbits[18:13] == 6'b000_000) )
  begin
     validaddr = 1;
  end
       else if ((addressbits[12] == 0) && (addressbits[18:13] == 6'b000_000) )
  begin
     validaddr = 1;
  end // else: !if((addressbits[12] == 1) && (addressbits[18:13] == 6'b000_000) )
       else
  begin
     validaddr = 0;
  end // else: !if((addressbits[12] == 0) && (addressbits[18:13] == 6'b000_000) )
    end // else: !if(!reset)
      end // block: infer1
 
// synopsys async_set_reset "reset"
/* synopsys async_set_reset_local infer2 "next_state, dtack_out, leftramRW, leftramCEbar, leftramOEbar, rightramRW, rightramCEbar, rightramOEbar, intoVME_E, intoRAM_E"*/
   always @ (reset or state or validaddr or vmewrite or ds0 or ds1 or as)
      begin : infer2
if (!reset)
    begin
       next_state <= 0;
       dtack_out <= 0;
       leftramRW <= 0;
       leftramCEbar <= 0;
       leftramOEbar <= 0;
       rightramRW <= 0;
       rightramCEbar <= 0;
       rightramOEbar <= 0;
       intoVME_E <= 0;
       intoRAM_E <= 0;
    end // if (!reset)
else
    begin
       case (state)
`nopSTATE:
begin
    intoRAM_E <= 0;
    intoVME_E <= 0;
    dtack_out <= 1;
 
    leftramCEbar <= 1;
    rightramCEbar <= 1;
 
    leftramRW <= 1;
    rightramRW <= 1;
 
    leftramOEbar <= 1;
    rightramOEbar <= 1;
 
    if ((validaddr == 1) && (vmewrite == 1) && (as == 0))
       begin
  next_state <= `readSTATE;
       end // if ((validaddr == 8'd1) && (write == 0))
    else if ((validaddr == 1) && (vmewrite == 0) && (as == 0))
       begin
  next_state <= `writeSTATE;
       end // else: !if((validaddr == 1) && (write == 0))
    else
       begin
  next_state <= `nopSTATE;
       end // else: !if((validaddr == 1) && (write == 1))
end // case: `nopSTATE
 
`writeSTATE:
begin
    intoVME_E <= 0;
    intoRAM_E <= 0;
    dtack_out <= 1;
 
    leftramCEbar <= 1;
    rightramCEbar <= 1;
 
    leftramRW <= 1;
    rightramRW <= 1;
 
    leftramOEbar <= 1;
    rightramOEbar <= 1;
 
    if ((ds0==0) && (ds1==0))
       begin
  next_state <= `wwordSTATE;
       end // if ((ds0==0) && (ds1==0))
    else if ((ds0==1) && (ds1==1))
       begin
  next_state <= `donewriteSTATE;
       end // else: !if((ds0==0) && (ds1==0))
    else
       begin
  next_state <= `wbyteSTATE;
       end // else: !if((ds0==0) && (ds1==0))
end // case: `writeSTATE
 
`wwordSTATE:
begin
    next_state <= `donewriteSTATE;
 
    leftramOEbar <= 1;
    rightramOEbar <= 1;
    leftramRW <= 0; // both chips receiving write
    rightramRW <= 0;
    leftramCEbar <= 0; // both chips on
    rightramCEbar <= 0;
 
    intoRAM_E <= 1;
    intoVME_E <= 0;
    dtack_out <= 1;
end // case: `wwordSTATE
 
`wbyteSTATE:
begin
    leftramOEbar <= 1;
    rightramOEbar <= 1;
    leftramRW <= 1;
    rightramRW <= 1;
    leftramCEbar <= 1;
    rightramCEbar <= 1;
 
    intoRAM_E <= 0;
    intoVME_E <= 0;
    dtack_out <= 1;
 
    if (ds0==0) // left write
       begin
  next_state <= `leftwriteSTATE;
       end // if (ds0==0)
    else
       begin
  next_state <= `rightwriteSTATE;
       end // else: !if(ds0==0)
end // case: `wbyteSTATE
 
`leftwriteSTATE:
begin
    leftramOEbar <= 1;
    rightramOEbar <= 1;
    leftramRW <= 0;
    rightramRW <= 1;
    leftramCEbar <= 0;
    rightramCEbar <= 1;
 
    intoRAM_E <= 1;
    intoVME_E <= 0;
    dtack_out <= 1;
 
    next_state <= `donewriteSTATE;
end // case: `leftwriteSTATE
`rightwriteSTATE:
begin
    leftramOEbar <= 1;
    rightramOEbar <= 1;
    leftramRW <= 1;
    rightramRW <= 0;
    leftramCEbar <= 1;
    rightramCEbar <= 0;
 
    intoRAM_E <= 1;
    intoVME_E <= 0;
    dtack_out <= 1;
 
    next_state <= `donewriteSTATE;
end // case: `rightwriteSTATE
 
`donewriteSTATE:
begin
    intoRAM_E <= 1;
    intoVME_E <= 0;
    dtack_out <= 0; // tell master i'm done
    // as is still low right now but will rise soon
    if (as == 1)
       begin
  next_state <= `wreleaseSTATE; // now release dtack
       end // if (as == 1)
    else
       begin
  next_state <= `donewriteSTATE; // waiting for as to rise
       end // else: !if(as == 1)
end // case: `donewriteSTATE
`wreleaseSTATE:
begin
    leftramOEbar <= 1;
    rightramOEbar <= 1;
    leftramRW <= 1;
    rightramRW <= 1;
    leftramCEbar <= 1;
    rightramCEbar <= 1;
 
    intoRAM_E <= 0;
    intoVME_E <= 0;
    dtack_out <= 1; // release dtack since i saw as rise
    next_state <= `nopSTATE; // back to origin
end // case: `wreleaseSTATE
 
 
// READMODE ** READMODE ** READMODE ** READMODE
 
 
`readSTATE:
begin
    leftramOEbar <= 1;
    rightramOEbar <= 1;
    leftramRW <= 1;
    rightramRW <= 1;
    leftramCEbar <= 1;
    rightramCEbar <= 1;
 
    intoRAM_E <= 0;
    intoVME_E <= 0;
    dtack_out <= 1;
 
    if ((ds0==0) && (ds1==0))
       begin
  next_state <= `rwordSTATE;
       end // if ((ds0==0) && (ds1==0))
    else
       begin
  next_state <= `rbyteSTATE;
       end // else: !if((ds0==0) && (ds1==0))
end // case: `readSTATE
 
`rwordSTATE:
begin
    next_state <= `donereadSTATE;
 
    leftramOEbar <= 0;
    rightramOEbar <= 0;
    leftramRW <= 1;
    rightramRW <= 1;
    leftramCEbar <= 0;
    rightramCEbar <= 0;
 
    intoRAM_E <= 0;
    intoVME_E <= 1;
    dtack_out <= 1;
 
end // case: `rwordSTATE
 
`rbyteSTATE:
begin
    leftramOEbar <= 1;
    rightramOEbar <= 1;
    leftramRW <= 1;
    rightramRW <= 1;
    leftramCEbar <= 1;
    rightramCEbar <= 1;
 
    intoRAM_E <= 0;
    intoVME_E <= 0;
    dtack_out <= 1;
    if (ds0==0) // left read
       begin
  next_state <= `leftreadSTATE;
       end // if (ds0==0)
    else
       begin
  next_state <= `rightreadSTATE;
       end // else: !if(ds0==0)
end // case: `rbyteSTATE
 
`leftreadSTATE:
begin
    next_state <= `donereadSTATE;
 
    leftramOEbar <= 0;
    rightramOEbar <= 1;
    leftramRW <= 1;
    rightramRW <= 1;
    leftramCEbar <= 0;
    rightramCEbar <= 1;
 
    intoRAM_E <= 0;
    intoVME_E <= 1;
    dtack_out <= 1;
end // case: `leftreadSTATE
`rightreadSTATE:
begin
    next_state <= `donereadSTATE;
    leftramOEbar <= 1;
    rightramOEbar <= 0;
    leftramRW <= 1;
    rightramRW <= 1;
    leftramCEbar <= 1;
    rightramCEbar <= 0;
 
    intoRAM_E <= 0;
    intoVME_E <= 1;
    dtack_out <= 1;
end // case: `rightreadSTATE
 
 
`donereadSTATE:
begin
 
    intoRAM_E <= 0;
    intoVME_E <= 1;
    dtack_out <= 0;
    if (as == 1)
       begin
  next_state <= `rreleaseSTATE; // now release dtack
       end // if (as == 1)
    else
       begin
  next_state <= `donereadSTATE; // waiting for as to rise
       end // else: !if(as == 1)
end // case: `donereadSTATE
 
`rreleaseSTATE:
begin
    leftramOEbar <= 1;
    rightramOEbar <= 1;
    leftramRW <= 1;
    rightramRW <= 1;
    leftramCEbar <= 1;
    rightramCEbar <= 1;
 
    intoRAM_E <= 0;
    intoVME_E <= 0;
    dtack_out <= 1;
    next_state <= `nopSTATE; // back to origin
end // case: `rreleaseSTATE
 
`zeroSTATE:
    begin
       dtack_out <= 1;
       intoRAM_E <= 0;
       intoVME_E <= 0;
       leftramCEbar <= 1;
       rightramCEbar <= 1;
       leftramOEbar <= 1;
       rightramOEbar <= 1;
       leftramRW <= 1;
       rightramRW <= 1;
       next_state <= `nopSTATE;
    end // case: zeroSTATE
 
default: // to take care of i nitial conditions
    begin
       dtack_out <= 1;
       intoRAM_E <= 0;
       intoVME_E <= 0;
       leftramCEbar <= 1;
       rightramCEbar <= 1;
       leftramOEbar <= 1;
       rightramOEbar <= 1;
       leftramRW <= 1;
       rightramRW <= 1;
       next_state <= `nopSTATE;
    end // case: default
       endcase // case (state)
    end // else: !if(!reset)
      end // block: infer2
endmodule


Article: 9958
Subject: Re: Survey of RTOS?
From: Alexander Teetaert <A.Teetaert@realtime-info.be>
Date: Fri, 17 Apr 1998 10:52:34 +0200
Links: << >>  << T >>  << A >>
> It runs in my mind that one of the subscribers to one of these two
> newsgroups had a survey of realtime operating systems (RTOS).  Where
> can I
> get a copy of that survey or download that survey?

We are the guys! Real-Time Magazine, the Brussels (Belgium) based
reference publication for the dedicated systems developer, has a RTOS
evaluation program. For an overview of our RTOS section, including info
on our evaluation program, see
http://www.realtime-info.be/encyc/market/rtos/rtos_home.htm

You also find there the URLs to the articles with specific results of
our survey. It was a big surprise to see OSE as most used RTOS in Europe
(it was a pan-European survey!).

Alexander Teetaert
Real-Time Magazine


Article: 9959
Subject: Macros for isp6000 from Lattice
From: "Sergio A. Cuenca Asensi" <sergio@dtic.ua.es>
Date: Fri, 17 Apr 1998 12:54:44 +0200
Links: << >>  << T >>  << A >>
Hello all, I`m trying to programm the isp6000 from Lattice, using Orcad
Express v7.1, but FIFOS and RAMS macro modules are not availables. Any
idea?
Thank you in advance.

--
===================================================================
Sergio A. Cuenca Asensi
Dept. Tecnologia Informatica y Computacion
Escuela Politecnica Superior, Campus de San Vicente
Universidad de Alicante
Ap. Correos 99, E-03080 ALICANTE
email   : sergio@dtic.ua.es
Phone : +34 6 590 34 00 ext. 3182
Fax     : +34 6 590 36 81
===================================================================


Article: 9960
Subject: Re: state machine
From: Tim Forcer <tmf@ecs.soton.ac.uk.nojunk>
Date: Fri, 17 Apr 1998 13:59:06 +0100
Links: << >>  << T >>  << A >>
Jaya_Kanajan wrote:
> 
>....
> 
> In the simulator, the fsm starts up in state 0, on the first clock
> it goes to the F state. Now, in both my F state and default state
> and 0'th state, I define two signals, leftramCEbar and rightramCEbar
> to both be high. (F state is nopstate) There is also a signal DTACK
> which I define to be high as well.
> 
> Now, in simulation, (unfortunately), the leftramCEbar and rightramCEbar
> start out low. Despite many attempts to fix this, we have failed. DTACK
> on the other hand starts out well and behaves decently. both the CEbar
> signals behave decently only after 6 state transitions later.
> 
> I attach portions of the code for your perusal....
>...

I don't speak Verilog, but wonder if you have defined the problem
signals to be combinational or registered.  And, if registered, whether
their clock is the same as the fsm clock. (I can't see anywhere obvious
in your code where this is done, although I think they are defined as
asynchronously- resettable registered signals clocked by same clock as
fsm - if this is so, it at least explains why the signals are low
following reset).

If registered with the same clock as fsm, then it depends how your
definitions are arranged whether the outputs change WITH fsm or AFTER. 
This is partly sort-of Mealy vs Moore configuration dependency.  If the
dependent outputs are registered Moore-type (ie dependent only on fsm
state) then they CAN'T change with the fsm, since the clock edge which
changes the fsm clocks the dependency logic for last state not current
state.  This problem is normally easy to spot, since the dependent
outputs are always one clock late.  With Mealy machines, the situation
is complicated by dependency on both fsm state and inputs, so the simple
one-clock delay pattern may not show up.  And if the clocks are
distinct, or if the dependent outputs get fed back at all (I know it
shouldn't happen, but it does!) then you could be in real trouble!

Good luck,

Tim Forcer               tmf@ecs.soton.ac.uk
Department of Electronics & Computer Science
The University of Southampton, UK

The University is not responsible for my opinions
Article: 9961
Subject: Re: XactStep6 - The cure for a dongle
From: z80@ds2.com (Peter)
Date: Fri, 17 Apr 1998 15:04:43 GMT
Links: << >>  << T >>  << A >>
Usually the MAC is held in a 93c46 or similar small serial EEPROM.


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.
Article: 9962
Subject: Question about DRAM market forcasts
From: Todd Kline <todd@wgate.com>
Date: Fri, 17 Apr 1998 11:40:51 -0400
Links: << >>  << T >>  << A >>
While this question is not specifically about FPGA's, it is likely
to be of general interest.  We are in the product planning stage
for a new development and need information on DRAM market
trends.  We are currently using a 4 Mbit (256K x 16) part and have
been told by two vendors that this part is going away by the end
of this year.

I found three vendors of DRAM market reports:
  Dataquest (about $2.5K),
  Integrated Circuit Engineering Corp. (ICE) (about $1K), and
  Instat (about $3K).

Does anyone have experience with these companies in general or
their DRAM reports in particular?  Any other suggested sources?

Dataquest is referanced often in industry trade journals, but that
doesn't mean thay have the best reports.

Thanks in advance,
Todd

Article: 9963
Subject: Re: state machine
From: Gareth Baron <gareth.baron@eng.efi.com>
Date: Fri, 17 Apr 1998 10:13:01 -0700
Links: << >>  << T >>  << A >>

--------------B07E20300764AEE7155E38F7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

It would probably also be a good idea to post this message to the Verilog
group as well.

I don't know what the exact problem as this hasn't appeared in my newsreader
(it's been garbage collected already!), but I would suspect that you are not
initialising the state machine correctly.  You could do this by;

module statemachine( clk ,out1, in1, async_reset) ;
input clk;
output out1;
input in1;

reg out1, in1;
reg [1:0] current_state;

parameter     STATE_1  = 2'b00,
              STATE_2  = 2'b01,
              STATE_3  = 2'b11,
              STATE_4  = 2'b10;

always @(posedge clk or posedge async_reset)
begin
    if(async_reset == 1'b1) begin
        out1 <= 1'b0;
        current_state <= STATE_1;        /* Initialise everything */
    end
    else begin
        case(current_state)
            STATE_1 :
                begin
                    if(in1 == 1'b0) begin
                        current_state <= STATE_2;
                        out1 <= 1'b0;
                    end
                end

            STATE_2 :
                begin
                    if(in1 == 1'b1) begin
                        current_state <= STATE_3;
                        out1 <= 1'b0;
                    end
                end

            STATE_3 :
                begin
                    if(in1 == 1'b1) begin
                        current_state <= STATE_2;
                        out1 <= 1'b1;
                    end
                end

            STATE_4 :
                begin
                    if(in1 == 1'b0) begin
                        current_state <= STATE_1;
                        out1 <= 1'b0;
                    end
                end
        endcase;
end

endmodule;


In this example (which I wrote off the top of my head, so please forgive any
syntax errors) the state machine is initialised into the correct state
(STATE_1) by an asyncronous reset which is positive logic.  You must do this
to initialise everything correctly and have a global reset to do this.  The
multiple posedge statement is used for FPGA's specifically.  If your state
machine starts in a random state (ie a non defined state), you must use the
'default:' condition in the case statement as this will bring you back to
safety.

If you have any furth questions please email me.


Tim Forcer wrote:

> Jaya_Kanajan wrote:
> >
> >....
> >
> > In the simulator, the fsm starts up in state 0, on the first clock
> > it goes to the F state. Now, in both my F state and default state
> > and 0'th state, I define two signals, leftramCEbar and rightramCEbar
> > to both be high. (F state is nopstate) There is also a signal DTACK
> > which I define to be high as well.
> >
> > Now, in simulation, (unfortunately), the leftramCEbar and rightramCEbar
> > start out low. Despite many attempts to fix this, we have failed. DTACK
> > on the other hand starts out well and behaves decently. both the CEbar
> > signals behave decently only after 6 state transitions later.
> >
> > I attach portions of the code for your perusal....
> >...
>
> I don't speak Verilog, but wonder if you have defined the problem
> signals to be combinational or registered.  And, if registered, whether
> their clock is the same as the fsm clock. (I can't see anywhere obvious
> in your code where this is done, although I think they are defined as
> asynchronously- resettable registered signals clocked by same clock as
> fsm - if this is so, it at least explains why the signals are low
> following reset).
>
> If registered with the same clock as fsm, then it depends how your
> definitions are arranged whether the outputs change WITH fsm or AFTER.
> This is partly sort-of Mealy vs Moore configuration dependency.  If the
> dependent outputs are registered Moore-type (ie dependent only on fsm
> state) then they CAN'T change with the fsm, since the clock edge which
> changes the fsm clocks the dependency logic for last state not current
> state.  This problem is normally easy to spot, since the dependent
> outputs are always one clock late.  With Mealy machines, the situation
> is complicated by dependency on both fsm state and inputs, so the simple
> one-clock delay pattern may not show up.  And if the clocks are
> distinct, or if the dependent outputs get fed back at all (I know it
> shouldn't happen, but it does!) then you could be in real trouble!
>
> Good luck,
>
> Tim Forcer               tmf@ecs.soton.ac.uk
> Department of Electronics & Computer Science
> The University of Southampton, UK
>
> The University is not responsible for my opinions



--



------------
Gareth Baron


--------------B07E20300764AEE7155E38F7
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
It would probably also be a good idea to post this message to the Verilog
group as well.

<P>I don't know what the exact problem as this hasn't appeared in my newsreader
(it's been garbage collected already!), but I would suspect that you are
not initialising the state machine correctly.&nbsp; You could do this by;<TT></TT>

<P><TT>module statemachine( clk ,out1, in1, async_reset) ;</TT>
<BR><TT>input clk;</TT>
<BR><TT>output out1;</TT>
<BR><TT>input in1;</TT><TT></TT>

<P><TT>reg out1, in1;</TT>
<BR><TT>reg [1:0] current_state;</TT><TT></TT>

<P><TT>parameter&nbsp;&nbsp;&nbsp;&nbsp; STATE_1&nbsp; = 2'b00,</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
STATE_2&nbsp; = 2'b01,</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
STATE_3&nbsp; = 2'b11,</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
STATE_4&nbsp; = 2'b10;</TT><TT></TT>

<P><TT>always @(posedge clk or <B>posedge async_reset</B>)</TT>
<BR><TT>begin</TT>
<BR><TT>&nbsp;&nbsp;&nbsp; if(<B>async_reset == 1'b1</B>) begin</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; out1 &lt;= 1'b0;</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current_state &lt;=
STATE_1;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* Initialise everything
*/</TT>
<BR><TT>&nbsp;&nbsp;&nbsp; end</TT>
<BR><TT>&nbsp;&nbsp;&nbsp; else begin</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; case(current_state)</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
STATE_1 :</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
begin</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
if(in1 == 1'b0) begin</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current_state &lt;= STATE_2;</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
out1 &lt;= 1'b0;</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
end</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
end</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
STATE_2 :</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
begin</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
if(in1 == 1'b1) begin</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current_state &lt;= STATE_3;</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
out1 &lt;= 1'b0;</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
end</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
end</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
STATE_3 :</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
begin</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
if(in1 == 1'b1) begin</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current_state &lt;= STATE_2;</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
out1 &lt;= 1'b1;</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
end</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
end</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
STATE_4 :</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
begin</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
if(in1 == 1'b0) begin</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current_state &lt;= STATE_1;</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
out1 &lt;= 1'b0;</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
end</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
end</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; endcase;</TT>
<BR><TT>end</TT><TT></TT>

<P><TT>endmodule;</TT>
<BR>&nbsp;

<P>In this example (which I wrote off the top of my head, so please forgive
any syntax errors) the state machine is initialised into the correct state
(STATE_1) by an asyncronous reset which is positive logic.&nbsp; You must
do this to initialise everything correctly and have a global reset to do
this.&nbsp; The multiple posedge statement is used for FPGA's specifically.&nbsp;
If your state machine starts in a random state (ie a non defined state),
you must use the 'default:' condition in the case statement as this will
bring you back to safety.

<P>If you have any furth questions please email me.
<BR>&nbsp;

<P>Tim Forcer wrote:
<BLOCKQUOTE TYPE=CITE>Jaya_Kanajan wrote:
<BR>>
<BR>>....
<BR>>
<BR>> In the simulator, the fsm starts up in state 0, on the first clock
<BR>> it goes to the F state. Now, in both my F state and default state
<BR>> and 0'th state, I define two signals, leftramCEbar and rightramCEbar
<BR>> to both be high. (F state is nopstate) There is also a signal DTACK
<BR>> which I define to be high as well.
<BR>>
<BR>> Now, in simulation, (unfortunately), the leftramCEbar and rightramCEbar
<BR>> start out low. Despite many attempts to fix this, we have failed.
DTACK
<BR>> on the other hand starts out well and behaves decently. both the
CEbar
<BR>> signals behave decently only after 6 state transitions later.
<BR>>
<BR>> I attach portions of the code for your perusal....
<BR>>...

<P>I don't speak Verilog, but wonder if you have defined the problem
<BR>signals to be combinational or registered.&nbsp; And, if registered,
whether
<BR>their clock is the same as the fsm clock. (I can't see anywhere obvious
<BR>in your code where this is done, although I think they are defined
as
<BR>asynchronously- resettable registered signals clocked by same clock
as
<BR>fsm - if this is so, it at least explains why the signals are low
<BR>following reset).

<P>If registered with the same clock as fsm, then it depends how your
<BR>definitions are arranged whether the outputs change WITH fsm or AFTER.
<BR>This is partly sort-of Mealy vs Moore configuration dependency.&nbsp;
If the
<BR>dependent outputs are registered Moore-type (ie dependent only on fsm
<BR>state) then they CAN'T change with the fsm, since the clock edge which
<BR>changes the fsm clocks the dependency logic for last state not current
<BR>state.&nbsp; This problem is normally easy to spot, since the dependent
<BR>outputs are always one clock late.&nbsp; With Mealy machines, the situation
<BR>is complicated by dependency on both fsm state and inputs, so the simple
<BR>one-clock delay pattern may not show up.&nbsp; And if the clocks are
<BR>distinct, or if the dependent outputs get fed back at all (I know it
<BR>shouldn't happen, but it does!) then you could be in real trouble!

<P>Good luck,

<P>Tim Forcer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
tmf@ecs.soton.ac.uk
<BR>Department of Electronics &amp; Computer Science
<BR>The University of Southampton, UK

<P>The University is not responsible for my opinions</BLOCKQUOTE>
&nbsp;

<P>--
<BR>&nbsp;
<BR>&nbsp;

<P>------------
<BR>Gareth Baron
<BR>&nbsp;</HTML>

--------------B07E20300764AEE7155E38F7--

Article: 9964
Subject: Re: Version Control for schematics?
From: "Bill Orner" <borner@pmc.philips.com>
Date: Fri, 17 Apr 1998 10:47:44 -0700
Links: << >>  << T >>  << A >>
We use Mcirosoft Source Safe with reasonably pleasant results.  The best
feature of Source Safe is that its easy to use and quick to set up.

-------------------------------------------------------------
Bill Orner
Manager, Hardware Engineering
Philips Multimedia Center

"The journey of a thousand miles begins with the first step"
-------------------------------------------------------------


Rick Filipkewicz wrote in message <3534BF0C.41C67EA6@algor.co.uk>...
>> In article <34fc3a8b.3807785@news.jps.net>, David Decker <mushh@jps.net>
>> writes
>
>> >I would like to use a version control system to support multiple
>> >FPGA designers doing ViewLogic schematic capture to
>> >Xilinx in under Win95. PVCS and similar programs are designed
>> [snip]
>
>Isn't this the strongest argument for moving to [text based]
>HDLs?  Then you have access to all the tried and tested tools s/w
>engineers have been using for years to control big designs :-
>GNU-Emacs + Language sensitive modes, RCS [Revision control],
>`make' [build control], etc.
>
>_________________________________________________________________________
>
> Dr. Richard Filipkiewicz phone: +44 171 700 3301
> Algorithmics Ltd. fax: +44 171 700 3400
> 3 Drayton Park email: rick@algor.co.uk
> London N5 1NU
> England


Article: 9965
Subject: XC4085xl pricing
From: David Peascoe <dwp@po.cwru.edu>
Date: Fri, 17 Apr 1998 19:33:29 -0400
Links: << >>  << T >>  << A >>
Does any one have current pricing information on the Xilinx 4085xl-2 or -3?

-- 
David             Praise your lord.        Web: Http://b62915.student.cwru.edu
"You know, tar sticks to some people. That's it. No more drugs for that man!"
"I once had a girl or should I say she once had me...here come old flat top he
come grooving up slowly he got joo joo eye balls he one holy roller he got 
hair down to his knee got to be a joker he just do what he please...what would
you think if I sang out of tune would you stand up and walk out on me...hey 
Jude...how does it feel to be one of the beautiful people"  The Beatles
Article: 9966
Subject: Verilog to VHDL or VHDL to Verilog
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 17 Apr 1998 17:17:05 -0700
Links: << >>  << T >>  << A >>
Does anybody know of a (semi)automatic translation tool between Verilog
and VHDL ?
If this is hopeless, please excuse my ignorance, but wouldn't it be nice
to have a choice of flavors, especially since there are geographical
preferences. ( e.g. US vs Europe ).

Peter Alfke, Xilinx Applications

Article: 9967
Subject: Re: Verilog to VHDL or VHDL to Verilog
From: zhangy <zhangy@isee.zju.edu.cn>
Date: Sat, 18 Apr 1998 18:46:27 +0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Does anybody know of a (semi)automatic translation tool between Verilog
> and VHDL ?
> If this is hopeless, please excuse my ignorance, but wouldn't it be nice
> to have a choice of flavors, especially since there are geographical
> preferences. ( e.g. US vs Europe ).
> 
> Peter Alfke, Xilinx Applications

See FAQ of VHDL
Article: 9968
Subject: Re: Question about DRAM market forcasts
From: Rickman <spamgoeshere1@yahoo.com>
Date: Sat, 18 Apr 1998 11:37:48 -0400
Links: << >>  << T >>  << A >>
Todd Kline wrote:
> 
> While this question is not specifically about FPGA's, it is likely
> to be of general interest.  We are in the product planning stage
> for a new development and need information on DRAM market
> trends.  We are currently using a 4 Mbit (256K x 16) part and have
> been told by two vendors that this part is going away by the end
> of this year.
> 
> I found three vendors of DRAM market reports:
>   Dataquest (about $2.5K),
>   Integrated Circuit Engineering Corp. (ICE) (about $1K), and
>   Instat (about $3K).
> 
> Does anyone have experience with these companies in general or
> their DRAM reports in particular?  Any other suggested sources?
> 
> Dataquest is referanced often in industry trade journals, but that
> doesn't mean thay have the best reports.
> 
> Thanks in advance,
> Todd

I assume that you are interested in these reports to determine if this
part is indeed going away. I don't know if you need to pay over a
kilobuck to get that info. I would trust my suppliers on that one. 

The 4 Mbit parts are two generations old at this point. I am sure that
they are at a higher cost per bit than either 16 Mbit and 64 Mbit parts.
They are likely not a lot cheaper per part than the most current
revision of the 16 Mbit parts. Other than trying to support an existing
design, why would you worry about this generation going out of
production? If you need manufacturing capability in the forseeable
future, can't you go ahead and buy what you expect you will need?

Rick Collins

rickman@XYwriteme.com

remove the XY to email me.


Article: 9969
Subject: Re: Question about DRAM market forcasts
From: z80@ds2.com (Peter)
Date: Sat, 18 Apr 1998 20:15:11 GMT
Links: << >>  << T >>  << A >>

>While this question is not specifically about FPGA's, it is likely
>to be of general interest.  We are in the product planning stage
>for a new development and need information on DRAM market
>trends.  We are currently using a 4 Mbit (256K x 16) part and have
>been told by two vendors that this part is going away by the end
>of this year.

There is a lot to be said for using "old" DRAM technology. It is
multi-sourced, and is likely to be cheapest per bit. I used to be in a
business where we used 300k+ DRAMs per year, and we were using the
1mbit (256k x 4) size until only a few years ago. They were dirt
cheap. Today I would use the 16mbit, probably.

Having said that, avoid using anything that is used *primarily* in PCs
(because those parts really do have short lifetimes) unless you can
replace it easily with something else.

There may be other reasons for moving to the latest devices, e.g. if
board space is at a premium.

>I found three vendors of DRAM market reports:
>  Dataquest (about $2.5K),

These forecasts are IMHO usually bogus. I can't recall the number of
these, forecasting e.g. a market of $2.3bn for something in the year
2005. Now, somebody tell me, how can anyone predict **whether there
will be a market for that part in 2005** let alone its size - to a
precision of TWO digits. I feel sorry for the people who pay for those
reports.

I recall reading an article in a UK electronics mag stating that one
of these forecasting firms have now lost most of their credibility,
because they get it wrong so often.

>Dataquest is referanced often in industry trade journals, but that
>doesn't mean thay have the best reports.

It is because they keep sending out press releases, and the mags need
something to fill the pages.


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.
Article: 9970
Subject: General Purpose Interface
From: A sharp <pc_interface@hotmail.com>
Date: Sat, 18 Apr 1998 14:06:50 -0700
Links: << >>  << T >>  << A >>
Hello,

     My name is Alan Sharp. I'm a third year student of Electronic
Engineering at Glasgow Caledonian University, in Scotland.

     As part of my final year's study, I am required to undertake
a project. My project is the creation of a General Purpose Interface,
with suitable software and reports, which is capable of controlling
a wide variety of different electronic systems ( I am using it to
control a Radio, a Stepper Motor, and a Video Recorder; but it could be
very easilly adapted to control practically any piece of electronic
equipment, or even to interface with a different computer system).

     I am undertaking the project as though it is a genuine commercial
product and I must therefore acquire some information regarding how
this item would be viewed in the marketplace.

     I would be very grateful, therefore, if you couls could reply to
me  with your own answers to the following six or seven questions.
     Obviously, as a student, I am not in a position to offer any 
financial or material incentive; but I would certainly be delighted
to send free copies of all schematics, simulations and reports pertinent
to the project to anyone who replies and who wants them, along with free
copies of the Windows & 68000 software required to
control the interface.

     Here are the questions:

1) Would you be prepared to purchase such a product if it were to become
commercially available?

2) How much do you think such a product would be worth? (Please specify
currency)

3) What would you use it to control?

4) Aside from software and hardware, what would you like to see included
with the product?

5) Please arrange these three words into what you view to be descending
order of importance as regards the product. (Most important first): 
PRICE     PERFORMANCE     ADAPTABILITY

6) Would it be imprtant to you that the interface and the device under
control were completely electrically isolated from your PC?

7) Do you have any other comments/ queries regarding the interface?


     

     Thank you for your time. 
     N.B. If you would like the schematics/software/simulations and
reports for the interface sent to you, please state so here.
     

Many thanks in advance,

Alan Sharp.
Article: 9971
Subject: Re: Xilinx Timing Constraints
From: Rickman <spamgoeshere1@yahoo.com>
Date: Sat, 18 Apr 1998 19:06:22 -0400
Links: << >>  << T >>  << A >>
ems wrote:
> 
> On Wed, 15 Apr 1998 23:24:29 -0400, Rickman <spamgoeshere1@yahoo.com>
> wrote:
> 
> > The best is a set of class handouts that were faxed to me.
> >In these handouts, there is a section on the multi-cycle clock problem.
> 
> any idea how i can get these? could you let us know who/where you got
> them from?
> 
> thanks
> 
> evan (ems@riverside-machines.com)


Evan,

I have a partial copy of class handouts labled "Timing & Constraints". I
have 24 pages, starting with slide 3 and runing to slide 59, missing
many slides here and there. 

I got them from a gentleman at Xilinx tech support named Bennet An.
Please contact them directly first. If you can't get them from Xilinx, I
could try faxing them when I get to the office (I work at home most of
the time). Or I could scan them in and email them (this may be a real
hassle for both of us). 

Try Xilinx first and let me know what happens. 


Rick Collins

rickman@XYwriteme.com

remove the XY to email me.
Article: 9972
Subject: Re: Verilog to VHDL or VHDL to Verilog
From: Zoltan Kocsi <root@127.0.0.1>
Date: 19 Apr 1998 14:01:14 +1000
Links: << >>  << T >>  << A >>
Peter Alfke <peter.alfke@xilinx.com> writes:

> Does anybody know of a (semi)automatic translation tool between Verilog
> and VHDL ?
> If this is hopeless, please excuse my ignorance, but wouldn't it be nice
> to have a choice of flavors, especially since there are geographical
> preferences. ( e.g. US vs Europe ).
> 
> Peter Alfke, Xilinx Applications

InterHDL has such a tool, available on unices (incl. Linux !) and of
course the obligatory Winblows.

The two-way tool is priced around $25K. You can have a 30-day trial 
license if you want to play with it.

Take a look at http://www.interhdl.com/

Zoltan

PS: I'm looking for a (semi)automatic translation tool from Verilog 
    to chip bitstream, preferably for free, on Linux :-)
    The chip in question is the one which has such a tool ...
	
-- 
+------------------------------------------------------------------+
| Reply address antispammed. Use ZOLTAN-at-BENDOR-dot-COM-dot-AU   |
+--------------------------------+---------------------------------+
| Zoltan Kocsi                   |   I don't believe in miracles   |  
| Bendor Research Pty. Ltd.      |   but I rely on them.           |
+--------------------------------+---------------------------------+
Article: 9973
Subject: Demonstrate the power of your FPGA system. Win $10k.
From: Peter Trei <trei@ziplink.net>
Date: Sun, 19 Apr 1998 00:40:06 -0500
Links: << >>  << T >>  << A >>
Would you like to demonstrate the power of your system,
reap major publicity, and win $10,000?

Do you have a massively parallel FPGA box, or a lot
of development boards sitting idle?

RSA Labs (http://www.rsa.com/rsalabs/des2/) has for 
the last couple of years been running "DES challenges", 
in which they publish a message encrypted using the 
DES (Data Encryption Standard) algorithm, and give 
cash prizes to the first person or group to decrypt it.

The idea is to use massive processing power to test every
possible key until a correct decryption is found (the first
few bytes of the encrypted message is known.) There are 2^56 
possible keys.

Two of these challenges have already been solved, both by
massive networks of conventional PCs. (For info, see 
www.distributed.net) The first took around 120 days, the 
second 39. To gain the $10k, the next must be solved in 
10 days or less (there are lower prizes for solving it 
in a longer period).

I believe that this is an application where FPGAs and other
configurable logic devices could really shine. I've done
some preliminary studies, and it looks like a DES keysearch
engine can definitely be done under 50k gates, and possibly
as low as 25k. A fully synchronous, pipelined design may be 
able to run as fast as 100 MHz, testing 1 key/clock, and 
has very minimal I/O requirements.

If anyone is interested in working on this, please contact me.
I've been studying this matter for some time, and have 
developed DES search engines for conventional microprocessors.
I'm a newbie to configurable logic, but learning fast.

Peter Trei
trei@ziplink.net

Disclaimer: I am an employee of Security Dynamics, the parent
company of RSA. Nevertheless, the above post represents only
my own personal views.
Article: 9974
Subject: FPGA programming info
From: Wilson Lee <WilsonBrianLee@yahoo.com>
Date: Sat, 18 Apr 1998 23:14:04 -0700
Links: << >>  << T >>  << A >>
I am looking for information on programming a real FPGA or SPGA,
preferrablely using JTAG ISP.  For instance, how do i link the
output of one gate to the input of another?  If you have any
information you are willing to share, please mailto:epl@rocketmail.com.
Thank you for any help.

In the alliance documents, there is a module "fpmap" for programming
FPGA, but it is not in the binary release.  I do not have access to
the source codes.  Can someone share a copy of the binary with me?

By the way, VHDL based Hardware Design Lab version 006 is now 
available for downloading at:

	http://www.best.com/~rod1/vhdl

This is still beta test software, use it at your own risk.
This version includes a simple gate array simulator PGA.  In debug
mode, PGA creates a full tracing of all inputs/outputs of port maps.
For example:

***** pga -d isa *****
NA(1)=1 <= INV(A(1)=0)
NA(0)=0 <= INV(A(0)=1)
NIOW=0 <= INV(IOW=1)
NWE=1 <= INV(WE=0)
SIG1(0)=1 <= AND4(vdd=1, NA(10)=1, A(9)=1, A(8)=1)
SIG1(1)=1 <= AND4(NA(7)=1, A(6)=1, NA(5)=1, NA(4)=1)
SIG1(2)=0 <= AND4(NA(3)=1, NA(2)=1, NA(1)=1, NA(0)=0)
WE=0 <= AND4(SIG1(2)=0, SIG1(1)=1, SIG1(0)=1, NIOW=0)
Q(1)=1 <= DLCA(D(1)=1, VSS=0, NWE=1)
Q(0)=1 <= DLCA(D(0)=1, VSS=0, NWE=1)


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