Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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: 9951lnwolf@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
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
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
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: 9955Hey 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
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 CummingsArticle: 9957
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> 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 MagazineArticle: 9959
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
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 opinionsArticle: 9961
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
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, ToddArticle: 9963
--------------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. 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 STATE_1 = 2'b00,</TT>
<BR><TT>
STATE_2 = 2'b01,</TT>
<BR><TT>
STATE_3 = 2'b11,</TT>
<BR><TT>
STATE_4 = 2'b10;</TT><TT></TT>
<P><TT>always @(posedge clk or <B>posedge async_reset</B>)</TT>
<BR><TT>begin</TT>
<BR><TT> if(<B>async_reset == 1'b1</B>) begin</TT>
<BR><TT> out1 <= 1'b0;</TT>
<BR><TT> current_state <=
STATE_1; /* Initialise everything
*/</TT>
<BR><TT> end</TT>
<BR><TT> else begin</TT>
<BR><TT> case(current_state)</TT>
<BR><TT>
STATE_1 :</TT>
<BR><TT>
begin</TT>
<BR><TT>
if(in1 == 1'b0) begin</TT>
<BR><TT>
current_state <= STATE_2;</TT>
<BR><TT>
out1 <= 1'b0;</TT>
<BR><TT>
end</TT>
<BR><TT>
end</TT><TT></TT>
<P><TT>
STATE_2 :</TT>
<BR><TT>
begin</TT>
<BR><TT>
if(in1 == 1'b1) begin</TT>
<BR><TT>
current_state <= STATE_3;</TT>
<BR><TT>
out1 <= 1'b0;</TT>
<BR><TT>
end</TT>
<BR><TT>
end</TT><TT></TT>
<P><TT>
STATE_3 :</TT>
<BR><TT>
begin</TT>
<BR><TT>
if(in1 == 1'b1) begin</TT>
<BR><TT>
current_state <= STATE_2;</TT>
<BR><TT>
out1 <= 1'b1;</TT>
<BR><TT>
end</TT>
<BR><TT>
end</TT><TT></TT>
<P><TT>
STATE_4 :</TT>
<BR><TT>
begin</TT>
<BR><TT>
if(in1 == 1'b0) begin</TT>
<BR><TT>
current_state <= STATE_1;</TT>
<BR><TT>
out1 <= 1'b0;</TT>
<BR><TT>
end</TT>
<BR><TT>
end</TT>
<BR><TT> endcase;</TT>
<BR><TT>end</TT><TT></TT>
<P><TT>endmodule;</TT>
<BR>
<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. 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.
<P>If you have any furth questions please email me.
<BR>
<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. 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.
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. This problem is normally easy to spot, since the dependent
<BR>outputs are always one clock late. 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. 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
tmf@ecs.soton.ac.uk
<BR>Department of Electronics & Computer Science
<BR>The University of Southampton, UK
<P>The University is not responsible for my opinions</BLOCKQUOTE>
<P>--
<BR>
<BR>
<P>------------
<BR>Gareth Baron
<BR> </HTML>
--------------B07E20300764AEE7155E38F7--
Article: 9964We 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 > EnglandArticle: 9965
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 BeatlesArticle: 9966
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 ApplicationsArticle: 9967
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 VHDLArticle: 9968
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
>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
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: 9971ems 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
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: 9973Would 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
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:
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