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
*** post for FREE via your newsreader at post.newsfeed.com ***
Hi all,
Does anyone know how to update the Aldec libraries for Xilinx devices?
I am running the student edition which limits file sizes to 10k, and I need
to compile and simulate XilinxCoreLib.blkmemdp_v4_0 but only v3_0 of the
library is included in the simulator.
Thanks for you help.
-----= Posted via Newsfeed.Com, Uncensored Usenet News =-----
http://www.newsfeed.com - The #1 Newsgroup Service in the World!
-----== 100,000 Groups! - 19 Servers! - Unlimited Download! =-----
Article: 45226
Hi,
I'm wondering if there is any good news on the availability of
the Xilinx Virtex-2 XC2V1500 and XC2V2000 parts? Are we
going to be able to get them soon?
Thanks.
--
Dick Ginther
Wavecom Electronics Inc
Article: 45227Pootle wrote: > I'm designing an system which requires a 622Mbps LVDS interface (4 > differential pairs). The signal has to pass between two boards a few inches > apart. Space on the boards isn't an issue (it's a prototype). We would > like to use any widely-available connector format. > > The LVDS signal is output from the TI SLK2501, i.e. not a line driver > device. > > Currently I'm planning on using 16-way twisted pair ribbon cable, on a > narrow-pitch header, with a hefty sprinkling of grounds, and termination as > per the data sheet. 622Mbps is faster than I've put into twisted pair, and when I did have to ship 800MHz clocks and edges around a system I took the cowards way out and used DIN-41612 mixed connectors with pairs of coax inserts - you can buy them from Farnell. You might get away with 622MHz with a really short cable. You probably don't need twisted pair, and it might pay you to use Teflon insulated ribbon - Teflon/PTFE insulation is much less lossy than polyvinylchloride (if much more expensive and a total swine to find). I'd use three wires per signal - ground, signal +, signal -, ground from next group. The structure is dispersive, but over a couple of inches this doesn't matter at 622MHz. and the characteristic impedance is a bit over 50R. ----- Bill Sloman, NijmegenArticle: 45228
> I'm in doubt that you'd succeed to find such a tool. Generally as the exact > configuration of the LUTs and switch boxes inside a FPGA device is kept > secret; there is no 3rd party place and route tool for any FPGA family. Atmel gives away this type of information under NDA, even when you're not a tool maker.Article: 45229
You can use the AMP Mictor connectors. They normally only go up to 0.9" board-to-board, but you can extend them by using Precision Interconnect's Blue Ribbon cable assemblies (50ohm micro coax). They come with Mictors on each end. Use the 0.26" bd-to-bd version of the Mictors, and then the PI cables in between. This solution will be expensive (several hundred dollars), but it will work well at those frequenies. Bob "Pootle" <Pootle(AT)mooses(DOT)co(DOT)uk> wrote in message news:uj8r3e6eahhgf5@corp.supernews.com... > I'm designing an system which requires a 622Mbps LVDS interface (4 > differential pairs). The signal has to pass between two boards a few inches > apart. Space on the boards isn't an issue (it's a prototype). We would > like to use any widely-available connector format. > > The LVDS signal is output from the TI SLK2501, i.e. not a line driver > device. > > Currently I'm planning on using 16-way twisted pair ribbon cable, on a > narrow-pitch header, with a hefty sprinkling of grounds, and termination as > per the data sheet. > > What would the group recommend? > > > >Article: 45230
Dear all, I would like to know the procedure of developing a simple MCU. Any website talk about this? I would like to develop the chip by verilog and implement by FPGA. Any suggestion for me? which free tools in good for me? Thank a lot. RealaArticle: 45231
Ken McElvain wrote:
> Arash Salarian wrote:
>
> > "jetmarc" <jetmarc@hotmail.com> wrote in message
> > news:af3f5bb5.0207151541.3188ca0a@posting.google.com...
> >
> >>Hi.
> >>
> >>Is anyone aware of 3rd party place & route tools for Atmels AT40K and
> >>
> > FPSLIC
> >
> >>series? I know that their own "Figaro IDS" is available on the web site.
> >>
> > I'm
> >
> >>looking for alternatives.
Probably not for routing...Although Atmel will give you the configuration bit
mapping under NDA with good justification, the parts are not a high enough blip
in the market to really justify a third party writing their own router.
Placement is a little easier, as you can put attributes in your edif netlist to
direct the placement. I don't recall the attribute names in Atmel (it has been
quite a while).
>
>
> >>
> >>
> >
> > I'm in doubt that you'd succeed to find such a tool. Generally as the exact
> > configuration of the LUTs and switch boxes inside a FPGA device is kept
> > secret; there is no 3rd party place and route tool for any FPGA family. So
>
The placer is the easy part as far as thrid party interfaces to the tools go.
You can get pretty far in Xilinx placement using RLOCs, Bels and area
constraints.
>
> This isn't actually true. Amplify (a physical synthesis tool) contains
> a placer for Virtex devices.
>
> > basically you're bound to use the vendors tool for this stage of the
> > design..
>
> >
> > Regards
> > Arash
> >
> >
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 45232On Tue, 16 Jul 2002 19:54:21 +0100, "Pootle" <Pootle(AT)mooses(DOT)co(DOT)uk> wrote: >I'm designing an system which requires a 622Mbps LVDS interface (4 >differential pairs). The signal has to pass between two boards a few inches >apart. Space on the boards isn't an issue (it's a prototype). We would >like to use any widely-available connector format. > >The LVDS signal is output from the TI SLK2501, i.e. not a line driver >device. > >Currently I'm planning on using 16-way twisted pair ribbon cable, on a >narrow-pitch header, with a hefty sprinkling of grounds, and termination as >per the data sheet. > >What would the group recommend? > > For a short run at this 'low' data rate, a regular (flat) ribbon cable should work fine. Grounds between signal pairs would be nice if you have room. JohnArticle: 45233
Hello, Thanks Benjamin and Peter. hmmmmmm, to tell you the truth, I don't know why, but I was not thinking of dual port RAMs at all.... why? I don't know... Maybe I was just thinking of maintaining source-code level portability between older Flex10KA devices (which was used in the previous version of the system) and newer devices. At least the soloution of using async. RAM was portable (though would consume far too much resources in architectures that did not support async. RAM) Yet in another thought, well, maybe I should not worry that much about it as all newer families in Xilinx and Altera include dual port RAM. thanks for your advices. Best Regards ArashArticle: 45234
"jetmarc" <jetmarc@hotmail.com> wrote in message news:af3f5bb5.0207161704.2f82f19f@posting.google.com... > > I'm in doubt that you'd succeed to find such a tool. Generally as the exact > > configuration of the LUTs and switch boxes inside a FPGA device is kept > > secret; there is no 3rd party place and route tool for any FPGA family. > > Atmel gives away this type of information under NDA, even when you're not > a tool maker. Yet I don't think such information is enough to write a Place and route software. As you see, there is no such tool as a 3rd party Place and route in the market at all (yeah, but maybe for very old devices like MAX5000....) Amplify, as reffered to by Ken is not a place and route tool, but rather a "physical optimizer" as it calls itself. It helps the vendors place and route tool a lot in terms of finding much better placement but has nothing to do with routing phase (but maybe just to ensure a routing is possible ...). Again in this case I doubt that Synplicity has ever had access to all detials of Virtex series configuration internals... Best Regards ArashArticle: 45235
"Erik" <vikinger@uni.de> wrote > > The "old" Virtex is a little bit outdated, ... > That do you mean? Virtex has an "new" familiy use XCV300E instead of XCV300. Maybe thats true and you get the newer parts cheaper. On the the other hand you might find someone with cheap prices who whish to get rid of the old parts. bye ThomasArticle: 45236
jdl1291@njit.edu (Joe Lawrence) wrote
> Greetings all, I am a newbie to FPGA & VHDL
[..]
> process (clk)
> begin
>
> if (clk'EVENT) AND (clk = '1') THEN
> -- flip flop code here
> end if;
Well I didn't mention if you don't call your self newbie :) That's bad
coding practise. Always use asynchronous reset/set until you know what
you do.
process (Clk, Reset)
begin
if Reset='1' then
FF<='0';
elsif Rising_Edge(Clk) then -- Function Risig_Edge is short for
Clk'Event and Clk='1'
-- FF code
end if;
Article: 45237
Hello all --
I downloaded a Verilog template for a Spartan II common-clock FIFO using
Block RAM from Xilinx from
ftp://ftp.xilinx.com/pub/applications/xapp/xapp175.zip .
I am using Xilinx Web Pack 4.2 Service Pack 2, and designing for a Spartan
IIe.
I also downloaded the latest version of the xilinxcore_ver libraries and
installed them in the correct directory in the ModelSim directory.
Still, when I simulate fifoctlr_cc.v (the file given from the ZIP above,
source code given in-line following message), all the outputs of the
bram4_s8_s8 primative are X's (unknown) in ModelSim.
I corrected a lot of warnings ModelSim was complaining about (not all the
outputs from the bram4_s8_s8 were connected (I connected one to a dummy
net); I wasn't using INIT_00, INIT_01, etc for initial values, and gave it
dummy values using the workaround for Synopsys described at
http://www.xilinx.com/xapp/xapp130.pdf )... but no luck. Then I tried
temporarily removing extra stuff like the clock buffer or some surrounding
control logic and simulating again ... still ... no luck :-(. So ModelSim
gives me no errors, but all I get out of the bram4_s8_s8 are X's!
Obviously, I have assigned input values to all my inputs in ModelSim. I've
also simulated non-block RAM modules from other projects and they work fine.
I also realize since this is a memory, theoretically the values are
*unknown* to start with, but I tried it with an initialization vector... and
all values are still X's... even ones that should be determinable like
"empty" and "full."
I saw one earlier posting about needing to change a line in the bram4_s8_s8
Verilog model and recompiling the library for ModelSim but it was for a
different version of ModelSim and WebPack... I thought I would ask first --
it seems a lot of people would want to simulate block RAM in Verilog
projects, and this was the simplest case I could come up with, and it
doesn't work :-(.
Any help/pointers/info, etc greatly appreciated :-).
Cheers,
John
/***********************************************************************\
* *
* Module : fifoctlr_cc.v Last Update: 12/13/99 *
* *
* Description : FIFO controller top level. *
* Implements a 511x8 FIFO with common read/write clocks. *
* *
* The following Verilog code implements a 511x8 FIFO in a Spartan-II *
* device. The inputs are a Clock, a Read Enable, a Write Enable, *
* Write Data, and a FIFO_gsr signal as an initial reset. The outputs *
* are Read Data, Full, Empty, and the FIFOcount outputs, which *
* indicate roughly how full the FIFO is. *
* *
\***********************************************************************/
`timescale 1ns / 10ps
`define DATA_WIDTH 7:0
`define ADDR_WIDTH 8:0
module fifoctlr_cc (clock_in, read_enable_in, write_enable_in,
write_data_in, fifo_gsr_in, read_data_out,
full_out, empty_out, fifocount_out );
input clock_in, read_enable_in, write_enable_in, fifo_gsr_in;
input [`DATA_WIDTH] write_data_in;
output [`DATA_WIDTH] read_data_out;
output full_out, empty_out;
output [3:0] fifocount_out;
wire read_enable = read_enable_in;
wire write_enable = write_enable_in;
wire fifo_gsr = fifo_gsr_in;
wire [`DATA_WIDTH] write_data = write_data_in;
wire [`DATA_WIDTH] read_data;
assign read_data_out = read_data;
reg full, empty;
assign full_out = full;
assign empty_out = empty;
reg [`ADDR_WIDTH] read_addr, write_addr, fcounter;
wire read_allow, write_allow;
assign read_allow = (read_enable && ! empty);
assign write_allow = (write_enable && ! full);
wire gnd = 0;
wire pwr = 1;
/**********************************************************************\
* *
* A global buffer is instantianted to avoid skew problems. *
* *
\**********************************************************************/
BUFGP gclk1 (.I(clock_in), .O(clock));
/**********************************************************************\
* *
* Block RAM instantiation for FIFO. Module is 512x8, of which one *
* address location is sacrificed for the overall speed of the design. *
* *
\**********************************************************************/
RAMB4_S8_S8 bram1 ( .ADDRA(read_addr), .ADDRB(write_addr), .DIB(write_data),
.DIA({gnd, gnd, gnd, gnd, gnd, gnd, gnd, gnd}),
.WEA(gnd), .WEB(write_allow), .CLKA(clock),
.CLKB(clock), .RSTA(gnd), .RSTB(gnd),
.ENA(read_allow), .ENB(pwr), .DOA(read_data) );
/***********************************************************\
* *
* Empty flag is set on fifo_gsr (initial), or when on the *
* next clock cycle, Write Enable is low, and either the *
* FIFOcount is equal to 0, or it is equal to 1 and Read *
* Enable is high (about to go Empty). *
* *
\***********************************************************/
always @(posedge clock or posedge fifo_gsr)
if (fifo_gsr) empty <= 1;
else empty <= (! write_enable && (fcounter[8:1] == 8'h0) &&
((fcounter[0] == 0) || read_enable));
/***********************************************************\
* *
* Full flag is set on fifo_gsr (but it is cleared on the *
* first valid clock edge after fifo_gsr is removed), or *
* when on the next clock cycle, Read Enable is low, and *
* either the FIFOcount is equal to 1FF (hex), or it is *
* equal to 1FE and the Write Enable is high (about to go *
* Full). *
* *
\***********************************************************/
always @(posedge clock or posedge fifo_gsr)
if (fifo_gsr) full <= 1;
else full <= (! read_enable && (fcounter[8:1] == 8'hFF) &&
((fcounter[0] == 1) || write_enable));
/************************************************************\
* *
* Generation of Read and Write address pointers. They use *
* LFSR counters, which are very fast. Because of the *
* nature of LFSRs, one address is sacrificed. *
* *
\************************************************************/
wire read_linearfeedback, write_linearfeedback;
assign read_linearfeedback = ! (read_addr[8] ^ read_addr[4]);
assign write_linearfeedback = ! (write_addr[8] ^ write_addr[4]);
always @(posedge clock or posedge fifo_gsr)
if (fifo_gsr) read_addr <= 'h0;
else if (read_allow)
read_addr <= { read_addr[7], read_addr[6], read_addr[5],
read_addr[4], read_addr[3], read_addr[2],
read_addr[1], read_addr[0], read_linearfeedback };
always @(posedge clock or posedge fifo_gsr)
if (fifo_gsr) write_addr <= 'h0;
else if (write_allow)
write_addr <= { write_addr[7], write_addr[6], write_addr[5],
write_addr[4], write_addr[3], write_addr[2],
write_addr[1], write_addr[0], write_linearfeedback };
/************************************************************\
* *
* Generation of FIFOcount outputs. Used to determine how *
* full FIFO is, based on a counter that keeps track of how *
* many words are in the FIFO. Also used to generate Full *
* and Empty flags. Only the upper four bits of the counter *
* are sent outside the module. *
* *
\************************************************************/
always @(posedge clock or posedge fifo_gsr)
if (fifo_gsr) fcounter <= 'h0;
else if ((! read_allow && write_allow) || (read_allow && ! write_allow))
begin
if (write_allow) fcounter <= fcounter + 1;
else fcounter <= fcounter - 1;
end
assign fifocount_out = fcounter[8:5];
endmodule
Article: 45238> Suppose I have an embedded processor and a host controller. > Host controller > sets a flag in a register, which causes in interrupt at the > embedded one. > When the interrupts is processed the embedded one clears the flag. > > This means that both sides must have access to the same flag. > This can be > solved with an asyncrhonous clear of the flipflop, but I was > wondering which > is most commonly done in this kind of situations. As someone else pointed out, a J-K (or R-S) FF will do fine if your processor and "host controller" share a common clock. However, if they have different clocks you have a clock domain problem and something similar to Jim Kearney's solution will work well. There's a nice description of one version of this technique written up by Bob Weinstein; he calls it the Flancter circuit. I don't know the background to his choice of name but it makes a Google search really easy... -- Jonathan Bromley HDL 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 This e-mail and any attachments are confidential and Doulos Ltd. = reserves all rights of privilege in respect thereof. It is intended for the use = of the addressee only. If you are not the intended recipient please delete = it from your system, any use, disclosure, or copying of this document = is unauthorised. The contents of this message may contain personal views = which are not the views of Doulos Ltd., unless specifically stated.Article: 45239
> What are good designs for mapping registers in an FPGA > into a microprocessors address space, to operate > like asynchronous > ram in terms of bus timing. > The read part seems pretty easy [...] agreed, as long as your FPGA can meet the bus cycle timing of the processor bus. > I guess there is a concern of > metastability when a status bit is changing during a read, is > this a problem I should be concerned with? Yes. But unless the read cycle is very fast, it's probably OK to have a bank of registers for the read data and clock that read register on the leading edge of the read strobe. The CPU will read it on the trailing edge, by which time all but the most pernicious metastability trouble should have settled down. Keep these "read cycle buffer" registers very closely coupled with the output and strobe pads so that all the timing is nice and predictable. > For writing the situation seems more complicated. Agreed; and I agree with you that it's not easy to find useful reference material. > because the FPGA clock is slower than the memory bus, such > that it would be > possible to do multiple writes per FPGA clock cycle. Eeek! Can't you get the FPGA to introduce wait states into the read cycle? > I've heard that FPGA have to build latches up from > combinatorial logic, and that their performance is quite poor? Yes, they are usually best avoided. > The Timing diagrams for the microprocessors I've looked at > make it look like > I can use the \WR signal as a rising edge clock, and then > decode the \CS and > ADDR lines for an ENABLE signal for D-FF registers. Is this a good > technique? It's OK as a method to write data from the bus into a bunch of registers just inside the FPGA - typically registers in the FPGA's I/O pads. This doesn't help with the multiple writes problem, though. > I can also see how one could use the embedded memory in > asynch mode to > implement the registers. This would certainly be a very low overhead > technique for the bus side, but would make it more > complicated accessing the > data inside the FPGA. I would probably have extra logic on > the back that > would take the synchronized write signal and use it to read > the written > memory to an internal register to hold for access by other > modules in the > design. If you have a lot of memory mapped writeable registers that are used only occasionally inside the FPGA (e.g. for configuration) this seems like a good way to do it. Sorry I can't be much more helpful - the same issue has caused me some heartache in the past. It's all soooo much easier if the FPGA and CPU/bus can share a clock. -- Jonathan Bromley HDL 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 This e-mail and any attachments are confidential and Doulos Ltd. = reserves all rights of privilege in respect thereof. It is intended for the use = of the addressee only. If you are not the intended recipient please delete = it from your system, any use, disclosure, or copying of this document = is unauthorised. The contents of this message may contain personal views = which are not the views of Doulos Ltd., unless specifically stated.Article: 45240
better in terms of area kayrock66@yahoo.com (Jay) wrote in message news:<d049f91b.0207142218.7a333adb@posting.google.com>... > Better is what way? Speed? Area? Ease of design/maintenance? Why > can't you just code the HDL and let the tools worry about the > implimentation? > > Regards > > "Hristo Stevic" <hristostev@yahoo.com> wrote in message news:<19654150d84919e93d2b683758967185.52609@mygate.mailgate.org>... > > Hello, > > i have 6 inputs of 12-bit wordlength to multiplex. > > i can use muxes using LUts. > > Is there any better way (TBUF?) to do it? > > target Xc4k or Virtex > > > > RegardsArticle: 45241
A great one for educative projects : PicoBlaze form Xilinx. I use it with my students, all is fine ... can be implemented with the free webpack ... (but no C, only asm language) Laurent Gauch for Amontec.com / Hevs.ch Reala wrote: > Dear all, > > I would like to know the procedure of developing a simple MCU. > Any website talk about this? I would like to develop the chip by verilog and > implement by FPGA. Any suggestion for me? which free tools in good for me? > Thank a lot. > > Reala > > > > >Article: 45242
Letting the tools do it is fine for the average design, but if you are concerned about speed, density, or consistency of results
from tool to tool you may find you need to provide the tools more of a hint. Generally speaking, the tools will not infer TBUFs
unless you specifically code tristates in the design, so that area saving implementation is not available unless you
specifically code for it.
Jay wrote:
> Better is what way? Speed? Area? Ease of design/maintenance? Why
> can't you just code the HDL and let the tools worry about the
> implimentation?
>
> Regards
>
> "Hristo Stevic" <hristostev@yahoo.com> wrote in message news:<19654150d84919e93d2b683758967185.52609@mygate.mailgate.org>...
> > Hello,
> > i have 6 inputs of 12-bit wordlength to multiplex.
> > i can use muxes using LUts.
> > Is there any better way (TBUF?) to do it?
> > target Xc4k or Virtex
> >
> > Regards
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 45243
Arash Salarian wrote:
> "jetmarc" <jetmarc@hotmail.com> wrote in message
> news:af3f5bb5.0207161704.2f82f19f@posting.google.com...
> > > I'm in doubt that you'd succeed to find such a tool. Generally as the
> exact
> > > configuration of the LUTs and switch boxes inside a FPGA device is kept
> > > secret; there is no 3rd party place and route tool for any FPGA family.
> >
> > Atmel gives away this type of information under NDA, even when you're not
> > a tool maker.
>
> Yet I don't think such information is enough to write a Place and route
> software. As you see, there is no such tool as a 3rd party Place and route
> in the market at all (yeah, but maybe for very old devices like MAX5000....)
Atmel does give you enough info to route the design under the NDA. We used it a
while back for the 6K devices to do some generators for some placed and routed
DSP macros. For a general purpose router, there is so much more architecture
specific stuff than just the bitstream coding to concern yourself with. It is
not a trivial effort by any stretch of the imagination. For that reason, you
are not likely to find 3rd party routers for devices that are not really
mainstream to begin with.
Amplify is not a router, It does placement using the mechanisms for externally
applied floorplanning provided by the FPGA tools. You still need to run the
design through the tool to get the full placement as well as the route and
bitstream.
>
>
> Amplify, as reffered to by Ken is not a place and route tool, but rather a
> "physical optimizer" as it calls itself. It helps the vendors place and
> route tool a lot in terms of finding much better placement but has nothing
> to do with routing phase (but maybe just to ensure a routing is possible
> ...). Again in this case I doubt that Synplicity has ever had access to all
> detials of Virtex series configuration internals...
>
> Best Regards
> Arash
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 45244
Even the 10KE has a dual port capability that would be satisfactory for meeting
this application requirement (dedicated read and write ports with separate
addresses and clocks).
Arash Salarian wrote:
> Hello,
>
> Thanks Benjamin and Peter.
> hmmmmmm, to tell you the truth, I don't know why, but I was not thinking of
> dual port RAMs at all.... why? I don't know...
> Maybe I was just thinking of maintaining source-code level portability
> between older Flex10KA devices (which was used in the previous version of
> the system) and newer devices. At least the soloution of using async. RAM
> was portable (though would consume far too much resources in architectures
> that did not support async. RAM)
>
> Yet in another thought, well, maybe I should not worry that much about it as
> all newer families in Xilinx and Altera include dual port RAM.
>
> thanks for your advices.
> Best Regards
> Arash
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 45245Thanks for your many replies - all very informative Does anyone have any experience with the AMP Champ range of interconnect? Product page: http://catalog.tycoelectronics.com/TE/bin/TE.Connect?C=10493&F=0&M=CINF&N=0&LG=1&I=42&RQS=C~10493^M~FEAT^G~G The PCB connector: http://catalog.tycoelectronics.com/TE/docs/pdf/6/49/158946.pdf The Cable (05m): http://catalog.tycoelectronics.com/TE/docs/pdf/6/88/174886.pdf With correct termination, how would this fare at 622Mbps? How would it compare to Mictor? -- Pootle At WorkArticle: 45247
Reala wrote: > I would like to know the procedure of developing a simple MCU. > Any website talk about this? I would like to develop the chip by verilog and > implement by FPGA. Any suggestion for me? which free tools in good for me? Please have a look at www.fpgacpu.org There you find more information about fpga-cpus then you probably ever asked for ;-) Have funArticle: 45248
I was happy to see the note about the "shielded twisted pairs" in the cable drawing. I cringed whenever I saw a suggestion for micro-coax (single signal) instead of some form of twisted pair (differential). The grounded shielding should give you great results with respect to crosstalk because there's little common mode junk left over in the differential signal. The fact that the LVDS signals come from one type of chip versus another should make no difference since the signalling standard specifies the currents that are generated to achieve the appropriate voltages across the 100 ohm differential termination. The 622M should be quite comfortable in your environment. Just don't forget to route those differential lines on your PCBs differentially - don't have one wire go northwest and the other one south when you come out of the driver or the connector. If you want the best precision, figure out the appropriate trace width and spacing for your dielectric based on the *differential* transmission line structure. Two 50 ohm transmission lines might not make the best 100 ohm differential pair. Any good PC board transmission line reference will have differential impedence calculations. Stick to those line/space guidelines for the pair and the signal will make you proud. JP Nicholls wrote: > Thanks for your many replies - all very informative > > Does anyone have any experience with the AMP Champ range of > interconnect? > > Product page: http://catalog.tycoelectronics.com/TE/bin/TE.Connect?C=10493&F=0&M=CINF&N=0&LG=1&I=42&RQS=C~10493^M~FEAT^G~G > > The PCB connector: http://catalog.tycoelectronics.com/TE/docs/pdf/6/49/158946.pdf > > The Cable (05m): http://catalog.tycoelectronics.com/TE/docs/pdf/6/88/174886.pdf > > With correct termination, how would this fare at 622Mbps? How would > it compare to Mictor? > > -- > Pootle At WorkArticle: 45249
> -----Original Message----- > From: Bill Sloman [mailto:bill.sloman@ieee.org] > Subject: Re: LVDS interface cable recommendation sought And what, may I ask, brings you here? I thought you didn't hold with all this new-fangled programmable logic stuff ? :-) -- Jonathan Bromley HDL 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 This e-mail and any attachments are confidential and Doulos Ltd. = reserves all rights of privilege in respect thereof. It is intended for the use = of the addressee only. If you are not the intended recipient please delete = it from your system, any use, disclosure, or copying of this document = is unauthorised. The contents of this message may contain personal views = which are not the views of Doulos Ltd., unless specifically stated.
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