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
2019JanFebMar2019

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 66625

Article: 66625
Subject: Re: Free PCI-bridge in VHDL for Spartan-IIE
From: knoll@infotech.tu-chemnitz.de (Knoll)
Date: 24 Feb 2004 05:35:30 -0800
Links: << >>  << T >>  << A >>
Dear Antti,

the code is provided free of charge via email.
However, no support or design guidance is guaranteed. 
Its use is at your own risk.
So, simply fill in the form and expect a brief email conversation.
( http://www.infotech.tu-chemnitz.de/~tlau/pci_bridge/kontakt.php3 )


Cheers,
Thomas
-- 
http://www.infotech.tu-chemnitz.de/~knoll/

"Antti Lukats" <antti@case2000.com> wrote in message news:<c1di1m$vqs$00$1@news.t-online.com>...
> Torsten,
> 
> what do you mean by "Free" ?
> on the link there is notice
> 
> "if interested please contact using a form" - there is no reference to any
> form or download location or conditions.
> so what it is all about?
> 
> also the website says the ref design uses Spartan III not IIE ?
> 
> antti
> www.openchip.org
>

Article: 66626
Subject: Re: Spartan 3 - avaliable in small quantities?
From: johnjakson@yahoo.com (john jakson)
Date: 24 Feb 2004 06:11:12 -0800
Links: << >>  << T >>  << A >>
Jim Granville <no.spam@designtools.co.nz> wrote in message news:<RDx_b.28109$ws.3170985@news02.tsnz.net>...
> "Hal Murray wrote:
> >>I suspect that the difficulty for just about any home grown processor is going to be the tools to compile the
> >>code for it, although folks who are more saavy than I on the software side might argue that the high speed
> >>hardware design is the hard part.
> > 
> > 
> > How much code are you writing?  Would you be willing/happy to do it in asembler?
> > 
> > Assemblers can be pretty simple, especially if the target is raw binary running
> > at loaded at 0 rather than something needing linkers and libraries.  Also helps
> > if the target is RISC and doesn't have messy addressing modes.
> > 
> > How much would a reasonably clean sample assembler help?  There should be
> > a good example from the academic world.  Just type in the new opcode table.
> 
> 
> "AS" from Alfred Arnold is a good wide-cores assembler, with a choice of 
> Pascal or C sources :
> 
> http://john.ccac.rwth-aachen.de:8000/as/download.html
> 
>   And HLA (High Level Assembler) is currently x86 only, but the front
> end, and approach is much closer to higher level languages (but minus 
> the bloat). V2 will allow different back ends, for opcode outputs.
>   Worth watching.
> 
> http://webster.cs.ucr.edu/AsmTools/HLA/index.html
> 
>   This is able to support quite large code efforts, and remain
> close to the iron..
> 
>   A benefit of working from the 'best assembler' end, is the ease of 
> support multiple/tiny core instances - which is one of the
> advantages of such soft cores.
> 
> -jg

Although an assembler is only a tiny fraction of the effort of a C
compiler, once done it only opens the door just enough to bootstrap up
slowly. For a processor to have much wider appeal needs the full
effort either to port or write from scratch.

I will probably set the hard type semantics of C aside for awhile and
just add a very quick dirty codegen that handles C style assembler and
simple 1 size expressions with none of the usual optimizations and
just play dumb. Then baseline C/Verilog/Occam/inline asm can be
written that might violate some proper rules. The compiler wouldn't be
able to compile itself but I could get on with testbench and
verification. Right now it can analyize itself but doesn't emit
anything. It does have a nice #preprocessor built into the lexer that
allows C++ like use of definitions with same name but varying no of
params that is not described in lcc book.

The usual way in the past was to define subsets of the target language
and compile for that with the compiler also being restricted to that
level. The 1st pass might be an assembler. The compiler could then
operate at some level on the target and as the language subset is
raised, the compiler gets to use the new features and tests them on
the next round. I don't think people do that anymore unless the
language is brand new and no compiler exists yet. Once it does exist,
it's usually easier to cross port.

This brings up a point, can a new compiler be $ distributed if the
design is largely based off of previous open code. I will have to go
check the license on lcc.

johnjakson_usa_com

Article: 66627
Subject: SHARC 21062/21060 link port implementation on Virtex 2 FPGA
From: "Joji John" <nansung444@yahoo.com>
Date: Tue, 24 Feb 2004 19:44:24 +0530
Links: << >>  << T >>  << A >>

Hi all,
    I need to know if any of you have implemented a SHARC link port on
above- mentioned FPGA. If so what tools did U use?
    Any info and direction will be gratefuly accepted.
--
end
Plain text reduces head-aches!!
" Cogito ergo, sum"
Joji John (nansung444@yahoo.com)
www.angelfire.com/ma3/joji
www.geocities.com/nansung444



Article: 66628
Subject: Re: SHARC 21062/21060 link port implementation on Virtex 2 FPGA
From: "Joji John" <nansung444@yahoo.com>
Date: Tue, 24 Feb 2004 19:52:45 +0530
Links: << >>  << T >>  << A >>
Hi,
    I would also appreciate ideas.
THanx.

--
end
Plain text reduces head-aches!!
" Cogito ergo, sum"
Joji John (nansung444@yahoo.com)
www.angelfire.com/ma3/joji
www.geocities.com/nansung444
Joji John <nansung444@yahoo.com> wrote in message news:...
>
> Hi all,
>     I need to know if any of you have implemented a SHARC link port on
> above- mentioned FPGA. If so what tools did U use?
>     Any info and direction will be gratefuly accepted.
> --
> end
> Plain text reduces head-aches!!
> " Cogito ergo, sum"
> Joji John (nansung444@yahoo.com)
> www.angelfire.com/ma3/joji
> www.geocities.com/nansung444
>
>



Article: 66629
Subject: SRAM bidirectional bus
From: ALuPin@web.de (ALuPin)
Date: 24 Feb 2004 06:48:48 -0800
Links: << >>  << T >>  << A >>
Hi,

I have a question concerning the VHDL description of a bidirectional bus.

This bus comes from (goes to) an SRAM which I try to simulate with 
a corresponding VHDL model.

Now I have an INOUT pin at my SRAM-Controller :  Sram_data : inout(7 downto 0);

Within my SRAM-Controller I have the local signals
l_sram_data_out : std_logic_vector(7 downto 0);
l_sram_data_in  : std_logic_vector(7 downto 0);


l_sram_data_out describes the data which I want to write into the SRAM.
l_sram_data_out is a registered signal.

l_sram_data_in describes the data I want to read from the SRAM.

The signal which is responsible for writing to the SRAM or reading out of
the SRAM is WE_bar.
WE_bar='0' & CS_bar='0' & OE_bar='1'  ---> Write to the SRAM
WE_bar='1' & CS_bar='0' & OE_bar='0'  ---> Read from the SRAM

How can I connect l_sram_data_out and l_sram_data_in 
in a appropriate way to the bidirectional bus? 

Does l_sram_data_in has to be synchronized? (It is used within the controller
in a synchronous environment)

I would appreciate any helpful hint.

Kind regards
André V.

Article: 66630
Subject: JTAG Opcodes for Altera MAX7000S
From: Patrik <pclad.adr@firemail.de>
Date: Tue, 24 Feb 2004 15:53:49 +0100
Links: << >>  << T >>  << A >>
Hi,

I try to program a JTAG chain with a MAX7064S and a MAX7032S via JTAG with 
a microcontroller. The problem is, that I couldn't find the JTAG opcodes 
for ISP. Is there any documentation about it?

Thanks,
Patrik

Article: 66631
Subject: Spartan 2 XC2S400E and XC2S600E availabillity
From: tau14@sussex.ac.uk (Ian)
Date: 24 Feb 2004 07:05:37 -0800
Links: << >>  << T >>  << A >>
Can recommend a decent supplier of the above parts in small qty for
the UK?

I've tried Emailing Insight Memec who have so far ignored me and
Digikey who apparently don't stock them!!

Also a supplier of NAND flash who also supply free simulation models
would be nice!! but that's another story.

Article: 66632
Subject: DCM Simulation Error
From: Timothy Campbell <tcampbel@uvm.edu>
Date: Tue, 24 Feb 2004 10:18:19 -0500
Links: << >>  << T >>  << A >>
I am using Modelsim SE 5.8 to simulate cascaded DCMs. I have two DCMs 
cascaded, the first with CLKIN running at 10Mhz. I am using the CLK2X of 
the first as the CLKIN for the second DCM. The desired output is CLK2X 
of the second DCM (I am trying to generate a 40Mhz clock from a 10Mhz 
clock). When I simulate, I recieve the following warning:

# ** Warning:  Timing Violation Error : Input Clock Period Jitter on 
instance * exceeds 0.001 ns Locked CLKIN Period =  0.1 ns Current CLKIN 
Period =  0.3 ns
#    Time: 675 ns  Iteration: 2  Instance: /dcmtest224/xlxi_1037

I cannot get the second DCM to lock as well. Any suggestions would be 
most appreciated.

Best Regards,
T. Justin Campbell

Article: 66633
Subject: spying on signals in Quartus (newbie question)
From: Vadim Rusu <vrusu@hep.uchicago.edu>
Date: Tue, 24 Feb 2004 09:41:05 -0600
Links: << >>  << T >>  << A >>
Hi,

When debugging a design one can assign inside the VHDL code debug pins. 
However, if after compiling and everything I decide to look for some 
other signal of choice (that are not pins), in the simulation, QUARTUS 
will give me a list of uninteligible names. Is there any way around 
this? Signal Tap seems to work only with a physical FPGA via JTAG.

Thanks
Vadim

Article: 66634
Subject: Re: SHARC 21062/21060 link port implementation on Virtex 2 FPGA
From: "MM" <mbmsv@yahoo.com>
Date: Tue, 24 Feb 2004 10:46:45 -0500
Links: << >>  << T >>  << A >>
"Joji John" <nansung444@yahoo.com> wrote in message
news:c1fmjj$1gpfg7$1@ID-219060.news.uni-berlin.de...
>
> Hi all,
>     I need to know if any of you have implemented a SHARC link port on
> above- mentioned FPGA. If so what tools did U use?
>     Any info and direction will be gratefuly accepted.

Yes, I've done it in VHDL. It is really not that difficult. Read carefully
the link port description in the DSP manual and create a state machine that
follows it.

/Mikhail



Article: 66635
Subject: Re: Spartan 2 XC2S400E and XC2S600E availabillity
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Tue, 24 Feb 2004 15:58:34 +0000 (UTC)
Links: << >>  << T >>  << A >>
Ian <tau14@sussex.ac.uk> wrote:
: Can recommend a decent supplier of the above parts in small qty for
: the UK?

: I've tried Emailing Insight Memec who have so far ignored me and
: Digikey who apparently don't stock them!!

: Also a supplier of NAND flash who also supply free simulation models
: would be nice!! but that's another story.

Nuhorizons list available parts. But probably they are prohibited by Xilinx
to ship those parts to the UK. Ask them!

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

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

Article: 66636
Subject: Re: Spartan 3 / XCF02S JTAG problem
From: jon@beniston.com (Jon Beniston)
Date: 24 Feb 2004 08:00:35 -0800
Links: << >>  << T >>  << A >>
> I have a board that has a XCF02S and Spartan 3 400 (ES) connected in a
> JTAG chain (the XCF02S is first in the chain). Attempting to
> initialise the chain in Impact fails because the IDCODE coming out of
> the FPGA is invalid (I have verified this on a scope - It is
> reproducibly incorrect, and always the same value). Looking at the TDO
> pin of the XCF02S / TDI pin of the FPGA, I can see that the IDCODE
> coming out of the XCF02S is correct.
> 
> If I take the XCF02S out of the chain, then the IDCODE from the FPGA
> is correct and Impact is able to program the device.
> 
> Should the value on the TDI pin of the FPGA effect the output of the
> IDCODE? 

I just tried reversing the order of the JTAG chain (FPGA first, then
PROM) and it now works. After numerious experiments, it seems that if
there is any activity on the FPGA's TDI pin, then the IDCODE wont be
output successfully.

Cheers,
JonB

Article: 66637
Subject: Re: Spartan 2 XC2S400E and XC2S600E availabillity
From: Leon Heller <aqzf13@dsl.pipex.com>
Date: Tue, 24 Feb 2004 16:00:39 +0000
Links: << >>  << T >>  << A >>


Ian wrote:

> Can recommend a decent supplier of the above parts in small qty for
> the UK?
> 
> I've tried Emailing Insight Memec who have so far ignored me and
> Digikey who apparently don't stock them!!

Try phoning them; distributors don't take much notice of emails, I've found.

> 
> Also a supplier of NAND flash who also supply free simulation models
> would be nice!! but that's another story.

-- 
Leon Heller, G1HSM
Email: aqzf13@dsl.pipex.com
My low-cost Philips LPC210x ARM development system:
http://www.geocities.com/leon_heller/lpc2104.html


Article: 66638
Subject: Re: FPGA vendors and their patents
From: paulfr@dacafe.com (Paul Franklin)
Date: 24 Feb 2004 08:23:29 -0800
Links: << >>  << T >>  << A >>
Austin Lesea <austin@xilinx.com> wrote in message news:<c1dko2$l603@cliff.xsj.xilinx.com>...
> ?
> 
> Of course, there are more patents that Xilinx has filed since then.
> 
> By the way, others have entered the FPGA business (an left it -- 
> unsuccessfully) and did not infringe on any patents, so it can be done.
> 
> Why did they not succeed?  Did it have to do with patents?
> 
> Nope.
> 
> Austin

Nope indeed. Why waste more money on lawyers' fees when the others can
self-destruct?
But I'll bet you are your buddies at Altera would have used your
patent portfolio at the whiff of any serious threat!

> 
> Steve Casselman wrote:
> > The earliest Xilinx patent is 4,870,302 Feb 19 1988. So it expires next year
> > 
> > Steve

Is this the famous Freeman patent?

> > 
> > "Paul Franklin" <paulfr@dacafe.com> wrote in message
> > news:518ec9d9.0402180243.2590fca0@posting.google.com...
> > 
> >>I heard something about some major FPGA patents due to expire soon. I
> >>think these are owned by Xilinx and/or Altera.
> >>
> >>I would be interested if anybody can clarify what exactly these
> >>patents are, and if anyone has an opinion on if their expiry could
> >>potentially enable market entry by new entrants to the FPGA arena or
> >>new product families by the exisiting FPGA vendors.
> >>
> >>Regards,
> >>Paul.
> >>
> > 
> > 
> >

Article: 66639
Subject: Verilog Newbie Question
From: "Kate Smith" <lsdjf@dlfjc.om>
Date: Tue, 24 Feb 2004 09:33:37 -0700
Links: << >>  << T >>  << A >>
The following code is my first Verilog program.  It's running at 25MHz and
that's what the counter is for.  I'm trying to accomplish the same thing by
shifting bits instead of hard coding the output in case statements.  I tried
LED<=LED>>1 to no avail.  Any comments and suggestions are appreciated!

Thanks!
Kate

module ledbounce(clk, LED);
input clk;
output [3:0] LED;

reg [19:0] cnt1;
reg [2:0] cnt2;
reg a, b, c, d;
wire cnt1max = (cnt1==1000000);

always @(posedge clk)
if(cnt1max)
 cnt1 <= 0;
else
 cnt1 <= cnt1 +1;

always @(posedge clk)
if(cnt1max)
begin
 if(cnt2==5)
 cnt2<=0;
 else
 cnt2<=cnt2+1;
end

always @(posedge clk)
begin
case(cnt2)
 0 : begin
  a = 1;
  b = 0;
  c = 0;
  d = 0;
  end
 1 : begin
  a = 0;
  b = 1;
  c = 0;
  d = 0;
  end
 2 : begin
  a = 0;
  b = 0;
  c = 1;
  d = 0;
  end
 3 : begin
  a = 0;
  b = 0;
  c = 0;
  d = 1;
  end
 4 : begin
  a = 0;
  b = 0;
  c = 1;
  d = 0;
  end
 5 : begin
  a = 0;
  b = 1;
  c = 0;
  d = 0;
  end
 endcase
end

assign LED[0] = a;
assign LED[1] = b;
assign LED[2] = c;
assign LED[3] = d;

endmodule



Article: 66640
Subject: Re: Spartan 3 - avaliable in small quantities?
From: johnjakson@yahoo.com (john jakson)
Date: 24 Feb 2004 08:38:25 -0800
Links: << >>  << T >>  << A >>
jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0402240132.7a92aa17@posting.google.com>...
> > Cache architecture is
> > currently 1 way set associative, but more Blockrams would allow more
> > ways.
> 
> Do you not think that the number of ways has to be as least as great
> as the number of threads? I would expect a significant amount of
> conflict misses (particularly in the I-Cache) if this is not the case.
> Hit-under-miss is a must.
> Otherwise all those impressive Mega-Hurtz will just be thown away
> stalling for cache refills.
> 
> Cheers,
> Jo

Hi Jon

Not neccesarily. On a conventional HT cpu, the threads would all be
independant, and likely fight over the cache set size and 2 way would
probably be a min. Since these threads are supposed to be cooperating
as Occam proceses would, then their opcodes would be local but that
assumes sibling processes run close to each other in time space. No
guarantee of that. In the HW event driven case, its much easier to
speculate about what will likely happen as the scheduling model is so
much simpler. Even if there are lots of conflicts what will happen is
the threads will just keep delaying.

In the HW time wheel, there are actually 16 threads waiting to go (or
null Ps if less available). These 16 represent the front of the proper
P queue stored in linklist out in memory space (only some of which
might be in cache at any time). The HW only allows the front 4 of
those to queue up in the Iop queue. The fetcher steals or forces
available cache reads slots to keep this full rotating between the 4
queues which live inside distributed 16b DP rams by 64 wide. Hence
each running thread can buffer up to 16 small ops or 4 extended 64b
ops or some mix.

On a side note, if the cpu were 64b wide, the HT would have to be
8way, but then the Iqueue HW would be twice as wide too so that still
allows each P to buffer up same no of ops. I would have to tweak the
HDL code to group the rams for hight v width keeping it 64b wide
output always. Wider data ops doesn't really change the opcode fetch
rate since that now looks half as much as before. The fractional costs
of executing ops now changes from 9/8 to 17/16 cycles for ALU a<-b OP
c; so a slight speed up. Putting large literals or actual addresses in
code space would wipe that out.


The fetcher also write the Pid with the opcodes and it does a
superficial check to see if any 16b ops are bra codes or not. If it
pushes a bra, it will then keep pushing just a few more words until
its past and then rotate that Pid out and take the next one from the
other 12 waiting.  The other side of the Iop queue just reads the 1-4
wide opcodes with the Pid and decode/execute the ops. It tracks the
opcode size and uses any bra codes as just another contol field. By
the time the bra decision is available, the Iop box will have executed
>>4 ops, but then it will have been P switched already. The bra
decision when it does arrive will post back the modified ip into the
Pid selected ip field. Pid rides along the datapath pipeline too. Bra
pts may be used to do the outer timesharing but I may leave that to a
SW kernal.

Cache misses will probably be treated same way, if the miss is going
to be long, switch to the next P in the side queue. You can imagine a
little railway track figure of 8 made up of selective pipelines &
muxes holding minimal P state. Something like Johnson logic or hot
coded state engine in charge.

One huge difference between this HT processor and the ones you hear
about x86, Alpha etc, I expect to use RLDRAM as 2nd level cache which
RAS cycles in 20ns  which is about 1.5 effective cpu cycles 13.3ns. It
is 8way banked and can support 2.5ns datarates and control. I will
probably be limited to the 311MHz rate and DDR is limited to 622MHz in
the specs (conveniant 2x), this is right on the edge of what FPGAs can
do and below the RLDRAM2 800MHz std.

Remember x86 in particular has to be designed to work with very slow
RAS elcheapo DDR Rams which can be several 100x slower than cpu
cycles. Intel can't do a special tweak for RLDRAM since the difference
is still very large, maybe 50 or more.

In this cpu I could almost throw cache out and go direct to RLDRAM as
main memory which is why I am not too concerned about tiny cache. I
will be building an RLDRAM model soon by faking a bunch of 8 Blockrams
together with delays and muxes demuxes. This will let me test out 1-8
cpu models running with faked RLDRAM all inside a sp-400 part. Further
a 64b 8way HT cpu would actually cycle slower than RLDRAM ie 26ns.

The real purpose of the cache which is a unified
data-instruction-workspace is to satisfy the enormous bandwith req of
the workspace operations. Reg cpus have 1 or more reg files separate
from d/i cache but they have the burden of very high swap contexts. R3
keeps many workspaces in uni cache and provide 3ports to datapath 2
reads and 2joined writes using a pair of DP rams. The instr and data
fetch requirements could be met by fast RLDRAM without cache, some
buffering would still be needed. The T9000 style workspace caching is
what makes this all work and that the cpus run close to RLDRAM speed.
If R3 ever went ASIC and n x faster, ofcourse the cache would go full
cuctom and bigger by far.

Hope that helps

johnjakson_usa_com

Article: 66641
Subject: Re: DCM Simulation Error
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 24 Feb 2004 08:40:45 -0800
Links: << >>  << T >>  << A >>
Timothy,

1)  You must hold the cascaded DM in reset until the first DCM has locked

2) The tool is correct, cascading DCM CLK2X is not recommended, as the 
jitter out of the first exceeds the specs of the input of the second.

They will work, but the resulting jitter out of the second one is not 
pretty (probably close to 400 to 600 ps P-P, which may be alright for 
your application).

Oh, and one last item, 10 MHz is too low a frequency to go into a DCM 
with (Fin min is > 24 MHz).

Austin

Article: 66642
Subject: Re: Free PCI-bridge in VHDL for Spartan-IIE
From: Sander Vesik <sander@haldjas.folklore.ee>
Date: Tue, 24 Feb 2004 16:52:21 +0000 (UTC)
Links: << >>  << T >>  << A >>
Kevin Brace <kev0inb1rac2e@m3ail.c4om> wrote:
> Hi,
> 
> Mine isn't going to be free, but . . . I am considering releasing a PCI
> IP core I have been working on for quite some time, and I am trying to
> gauge the demand out there for a commercial-grade PCI IP core for
> personal users.
> However, the PCI IP core itself probably won't be available for another
> three months at the earliest (I still need to fix some minor problems,
> and setup the infrastructure before the release.).
> The price I am thinking of charging for my PCI IP core is only $100
> (USD) as long as the licensee meets the following conditions.
> 
> * The licensee resides within the United States (Don't have to be a US
> citizen.).
> * The licensee Will agree that the PCI IP core will be used only for
> non-commercial, non-profit, non-academic research, and personal
> purposes.
> * The licensee is will agree, sign, and mail back to a license agreement
> form I will provide.
> * The licensee will pay for the PCI IP core license through an online
> payment source like PayPal.
> 

Rather heavy-handed set of restrictions, don't you think?

-- 
	Sander

+++ Out of cheese error +++

Article: 66643
Subject: Re: Verilog Newbie Question
From: "Jonathan Bromley" <jonathan.bromley@doulos.com>
Date: Tue, 24 Feb 2004 17:19:10 -0000
Links: << >>  << T >>  << A >>
"Kate Smith" <lsdjf@dlfjc.om> wrote in message
 news:bNidnZqo8vXL4KbdRVn-uQ@comcast.com...
> The following code is my first Verilog program.  It's running at 25MHz and
> that's what the counter is for.  I'm trying to accomplish the same thing
by
> shifting bits instead of hard coding the output in case statements.  I
tried
> LED<=LED>>1 to no avail.  Any comments and suggestions are appreciated!

> module ledbounce(clk, LED);
> input clk;
> output [3:0] LED;
>
> reg [19:0] cnt1;
> reg [2:0] cnt2;
> reg a, b, c, d;
> wire cnt1max = (cnt1==1000000);

[snip code]

First, it's worth noting that you are more likely to get an
answer on comp.lang.verilog than here - although many of us
read both groups.

Second, you can't manipulate output LED as you tried, because
it's a wire, not a reg - you declared it correctly as an
output, but outputs are wires by default.  You need to do the
shift operations on the register you've represented as
a,b,c,d.

Third, although I can see the sense in your counter arrangement,
the second counter is not really necessary - you could use the
"bouncing bit" 4-bit register as its own counter.

Fourth, you REALLY need to think about reset strategy -
in many FPGA and CPLD devices, flip-flops start life with
zero in them, but it's a bad idea to rely on this.

So, here's my suggestion:

(1) Throw away your cnt2 logic and registers a,b,c,d.
(2) Make the bouncing-bit counter like this:

reg LeftNotRight;
reg [3:0] LED;  // This in addition to the output declaration
...
always @(posedge clk or posedge reset)
  if (reset) begin
    LED <= 1;
    LeftNotRight <= 1;
  end else if (cnt1max) begin
    if (LeftNotRight) begin // Going left
      if (LED[3])
        LeftNotRight <= 0;
      else
        LED <= LED << 1;
    end else begin // Going right
      if (LED[0])
        LeftNotRight <= 1;
      else
        LED <= LED >> 1;
    end
  end

For lots of extra credit, see if you can work out
a) what happens if the LED register gets more than
   one of its bits set, for any reason;
b) what happens if the LED register becomes zero
   for any reason, and what you might do to fix it

:-)

--

Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                    mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 66644
Subject: Re: Why does Xilinx keep saying LVPECL_2.5 and _3.3V are identical?
From: symon_brewer@hotmail.com (Symon)
Date: 24 Feb 2004 09:20:50 -0800
Links: << >>  << T >>  << A >>
qlyus,
     I don't know, but I suspect that this is the case:-
1) The differential receivers works over a very large common mode
range. The common mode voltage probably affects the switching speed
though.
2) The receivers work with very small differential voltages, with the
gotcha being that the smaller the differential voltage the slower the
switching.
3) Xilinx only test the parts to the specifications you quote, because
they can't, or it's too expensive to, check all inputs over all common
mode voltages and differential voltages meet all timing for every part
off the production line.

     So, it's physically the *same* receiver, it's just only tested at
the two LVPECL (and the LVDS I guess) points you quote.
     Good luck, Symsx.

Article: 66645
Subject: Re: Verilog Newbie Question
From: "Kevin Neilson" <kevin_neilson@removethiscomcast.net>
Date: Tue, 24 Feb 2004 17:30:33 GMT
Links: << >>  << T >>  << A >>
>
> Second, you can't manipulate output LED as you tried, because
> it's a wire, not a reg - you declared it correctly as an
> output, but outputs are wires by default.  You need to do the
> shift operations on the register you've represented as
> a,b,c,d.
>

I don't see why what she's done wouldn't work.  Her registers a,b,c, and d
change at the clock edge and the LED wires are connected to the outputs of
the registers.

The only problem I might see is that it runs a bit fast.  The "state
machine" changes states at 25Hz and it might be hard to see the LEDs blink
that quickly.

-Kevin



Article: 66646
Subject: Re: Verilog Newbie Question
From: "Jonathan Bromley" <jonathan.bromley@doulos.com>
Date: Tue, 24 Feb 2004 17:45:41 -0000
Links: << >>  << T >>  << A >>
"Kevin Neilson" <kevin_neilson@removethiscomcast.net>
wrote in message news:ZSL_b.5237$AL.131989@attbi_s03...

> I don't see why what she's done wouldn't work.  Her registers a,b,c, and d
> change at the clock edge and the LED wires are connected to the outputs of
> the registers.

The code as presented was fine, yes.  I was talking about the
attempt to set LED <= LED >> 1, as mentioned at the start of the
original post.  Sorry I didn't make that clear.

--

Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                    mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 66647
Subject: Re: FPGA vendors and their patents
From: "MaEs" <thedude@DieSpamBots.xs4all.nl>
Date: Tue, 24 Feb 2004 18:56:32 +0100
Links: << >>  << T >>  << A >>
> >
> > Steve Casselman wrote:
> > > The earliest Xilinx patent is 4,870,302 Feb 19 1988. So it expires
next year
> > >
> > > Steve
>
> Is this the famous Freeman patent?
>
> > >

Likely, although one company A. might refer to it as 'infamous'  :) :)


US4870302:

"Configurable electrical circuit having configurable logic elements and
configurable interconnects"

Inventor: Ross H. Freeman, San Jose, Calif.

Assignee: Xilinx, Inc., San Jose, Calif.



Article: 66648
Subject: Re: Routing algorithm - help needed
From: Dave <recneps.w.divad@elcaro.moc>
Date: Tue, 24 Feb 2004 18:01:06 +0000
Links: << >>  << T >>  << A >>


Chris Jones wrote:
> Consider the grid shown below. 
> 
> There are 4 electrical "switch pairs" which need to be connected to
> make the overall connection work.
> 
> ---------------------------------------------------------
> |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
> ---------------------------------------------------------
> |   |   |   |   |   |   |   |   |   |   |   |   |   | c`|
> ---------------------------------------------------------
> |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
> ---------------------------------------------------------
> |   |   |   | b |   |   |   |   |   |   |   |   |   |   |
> ---------------------------------------------------------
> |   |   |   |   |   |   |   |   |   |   |   |   | d'|   |
> ---------------------------------------------------------
> |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
> ---------------------------------------------------------
> |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
> ---------------------------------------------------------
> |   |   |   |   |   | a |   |   |   |   | a`|   |   |   |
> ---------------------------------------------------------
> |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
> ---------------------------------------------------------
> |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
> ---------------------------------------------------------
> |   |   |   |   |   |   |   |   |   |   | b`|   |   |   |
> ---------------------------------------------------------
> |   |   |   |   |   |   | d |   |   |   |   |   |   |   |
> ---------------------------------------------------------
> |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
> ---------------------------------------------------------
> |   | c |   |   |   |   |   |   |   |   |   |   |   |   |
> ---------------------------------------------------------
> 
> The paths are
> 
>         a ---   a'  (path A)
>         b ---   b'  (path B)
>         c ---   c'  (path C)
>         d ---   d'  (path D)
> 
> There would be two possible routes to connect these paths. The
> connection can follow either  1) horizontal then vertical direction,
> or 2) vertical then  horizontal direction. There ie no other way that
> the path between the electrical switches could be made. Thus every
> possible path here would make a bounded rectangle encompassing the
> pair of  switches.
> 
> The following rule is to be followed for making up these paths:
> 
> If a switch p belonging to one path lies in the bounded rectangle
> formed by the switches belonging to another path, then path p must be
> connected first.
> 
> SO - What would be the order of connectivity of this set of paths?
> 
> AND - Develop a generalized procedure to implement this strategy!
> 
> Thanks,
> Chris


First, determine how you would do this in your head.  Then try to do it 
on paper.  Then pretend to be a dumb computer and do it on paper again. 
  Then you should have a good idea how the program will work.

Seems, unless I've misread it, that this network is soluble in 
alphabetical order:
a-a': trivial.
b-b': across/down fails because of a-a'; down/across works.
c-c': could go either way
d-d': up/right crosses a-a' but right/up is ok.

So in my head I'm marking cells that have been visited by existing 
connections, then for subsequent connections considering if those cells 
are already occupied.  It's not hard to see that in other arrangements, 
abcd might not be possible but some other order is, so you'll need to 
run through the possible variations from abcd to dcba, listing the 
orders that work.

Dave.

Article: 66649
Subject: Experience with Simulating RocketIO in Modelsim
From: Timothy Campbell <tcampbel@uvm.edu>
Date: Tue, 24 Feb 2004 13:22:02 -0500
Links: << >>  << T >>  << A >>
Does anyone have any experience simulating RocketIO in Modelsim SE via 
use of SmartModels. I am trying to stimulate the TXP and TXN pins of the 
MGT via use of a .do file. Is there are proper way to do this, or is the 
following acceptable:

restart -f
force RocketIO_10mhz 0 0ns, 1 50ns -repeat 100ns
run 2us
run 50ns
force RXNIn1_Data 1
force RXPIn1_Data 0
run 100ns
force RXNIn1_Data 1
force RXPIn1_Data 0
run 100ns
force RXNIn1_Data 1
force RXPIn1_Data 0
run 100ns
force RXNIn1_Data 0
force RXPIn1_Data 1
run 100ns
force RXNIn1_Data 0
force RXPIn1_Data 1
run 100ns
force RXNIn1_Data 0
force RXPIn1_Data 1
run 100ns
force RXNIn1_Data 1
force RXPIn1_Data 0
run 100ns
force RXNIn1_Data 1
force RXPIn1_Data 0
run 100ns
force RXNIn1_Data 0
force RXPIn1_Data 1
run 100ns
force RXNIn1_Data 1
force RXPIn1_Data 0
run 100ns

p.s. The input clock to the MGT is running at 40Mhz

Best Regards,
T. Justin Campbell



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
2019JanFebMar2019

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