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 Joseph, "Altera: hardcopy-II - these are structured ASICs. They look appealing, but I did not get the impression that there were many conversions (at least as of a year ago)." We have many customers lined up to use HardCopy II, and have have had a significant number of conversions in the original HardCopy devices; one example is TI's DLP chipset (yes, I'm talking about those fancy HDTVs). HardCopy II is particularly exciting because it uses a very efficient fine-grained logic fabric and provides a choice of migration devices allowing greater cost reductions than previous members of the family. HardCopy II also provides a significant speed-up over the equivalent Stratix II FPGA devices and cuts power consumption in half. I don't know why LSI is exiting this market. But there are a few advantages Altera has offering a structured ASIC over pure-play structured ASIC vendors. First, we can leverage existing sales channels and contacts from our FPGA products; selling a structured ASIC is a lot more like selling an FPGA than it is selling a standard-cell ASIC product. Second, our customers can prototype immediately in an FPGA, and can sell that prototype for as long as it takes them to finalize their design and commit to the HardCopy II device. They can wait for their product to take-off before migrating to HardCopy II for a cost-reduction, or they can move immediately into HardCopy II in order to attain speed, power and cost advantages. Third, and certainly not last, we can leverage our software and intellectual property from our FPGAs. We put a full-fledged CAD suite (Quartus II) on the customer's desktop, allowing them to design, iterate, and close timing before handing off the design to us. The software is easy-to-use (especially by ASIC standards), giving push-button RTL-to-Silicon results. In addition, we have a large library of Altera and 3rd-party intellectual soft-IP that customers can use in their designs that have been tested in numerous FPGA designs. And HardCopy II devices incorporate much of the hard-IP from our FPGA devices, such as PLLs, I/Os and RAMs, and work the same way as the Stratix II FPGA. Regards, Paul Leventis Altera Corp.Article: 98426
> After all, in spite of the best spin efforts from all the marketing > departments, the Silicon performances are actually quite similar - > expected given they depend mostly on what Process the leading edge FABs > can run. Hi Jim, Actually, there is a lot of R&D spent on the logic and routing architectures of FPGAs (never mind other integrated IP) that has a large influence on the speed of the resulting chip. And then there's the software... what is the difference between transistors getting faster by 5% and an algorithm enhancement in the placer (for example) that gives 5%? From a user's perspective, nothing. Lets pretend for a moment that Altera & Xilinx high-end FPGAs are the same speed (based on our experiments, Stratix II has a considerable advantage, but anyway...). The reason for this is not because its easy to make good FPGAs, but because both Altera and Xilinx employee a large number of smart, experienced FPGA architects, IC Designers, and Software engineers that are capable of wringing out every drop of performance they can. These innovations result in improved performance from one generation to the next, more than would have been possible by process technology alone. Sure, process technology helps, but even that isn't as free as it used to be -- it takes a lot more effort these days to simultaneously gain speed, reduce area and keep power under control when moving to new processes. Regards, Paul Leventis Altera Corp.Article: 98427
paulleventis-public@yahoo.ca wrote: > Hi Joseph, > > "Altera: hardcopy-II - these are structured ASICs. They look > appealing, but > I did not get the impression that there were many conversions (at least > as > of a year ago)." > > We have many customers lined up to use HardCopy II, and have have had a > significant number of conversions in the original HardCopy devices; one > example is TI's DLP chipset (yes, I'm talking about those fancy HDTVs). > HardCopy II is particularly exciting because it uses a very efficient > fine-grained logic fabric and provides a choice of migration devices > allowing greater cost reductions than previous members of the family. > HardCopy II also provides a significant speed-up over the equivalent > Stratix II FPGA devices and cuts power consumption in half. > > I don't know why LSI is exiting this market. But there are a few > advantages Altera has offering a structured ASIC over pure-play > structured ASIC vendors. First, we can leverage existing sales > channels and contacts from our FPGA products; selling a structured ASIC > is a lot more like selling an FPGA than it is selling a standard-cell > ASIC product. > > Second, our customers can prototype immediately in an FPGA, and can > sell that prototype for as long as it takes them to finalize their > design and commit to the HardCopy II device. They can wait for their > product to take-off before migrating to HardCopy II for a > cost-reduction, or they can move immediately into HardCopy II in order > to attain speed, power and cost advantages. > > Third, and certainly not last, we can leverage our software and > intellectual property from our FPGAs. We put a full-fledged CAD suite > (Quartus II) on the customer's desktop, allowing them to design, > iterate, and close timing before handing off the design to us. The > software is easy-to-use (especially by ASIC standards), giving > push-button RTL-to-Silicon results. In addition, we have a large > library of Altera and 3rd-party intellectual soft-IP that customers can > use in their designs that have been tested in numerous FPGA designs. > And HardCopy II devices incorporate much of the hard-IP from our FPGA > devices, such as PLLs, I/Os and RAMs, and work the same way as the > Stratix II FPGA. Who bears the cost, if the hardcopy migrate fails ? How many of the Hardcopy II have not worked after the move to ASIC, and needed a re-spin ? -jgArticle: 98428
Paul Leventis wrote: >> After all, in spite of the best spin efforts from all the marketing >>departments, the Silicon performances are actually quite similar - >>expected given they depend mostly on what Process the leading edge FABs >>can run. > > > Hi Jim, > > Actually, there is a lot of R&D spent on the logic and routing > architectures of FPGAs (never mind other integrated IP) that has a > large influence on the speed of the resulting chip. And then there's > the software... what is the difference between transistors getting > faster by 5% and an algorithm enhancement in the placer (for example) > that gives 5%? From a user's perspective, nothing. > > Lets pretend for a moment that Altera & Xilinx high-end FPGAs are the > same speed (based on our experiments, Stratix II has a considerable > advantage, but anyway...). The reason for this is not because its easy > to make good FPGAs, but because both Altera and Xilinx employee a large > number of smart, experienced FPGA architects, IC Designers, and > Software engineers that are capable of wringing out every drop of > performance they can. These innovations result in improved performance > from one generation to the next, more than would have been possible by > process technology alone. > > Sure, process technology helps, but even that isn't as free as it used > to be -- it takes a lot more effort these days to simultaneously gain > speed, reduce area and keep power under control when moving to new > processes. Yes, but my statement still stands. The devices nett performances ( SW and Silicon combined ) are actually quite similar - there is not a 4:1 edge, as one could expect from a 15% improvement every year, for a decade. Same with Intel and AMD. Years of effort, and still very similar results. Instead, the marketing depts have to resort to selective spin, to try and make each iteration sound larger than it really is. -jgArticle: 98429
> Can I consider the power estimation confidence in the first case medium as > in the second case, knowing that if the estimation is low, it's just because > I have intentionally not used half (1 filter out of 2) of the design ? Hi, Yes, that's exactly it. We had a tough design decision on how to handle zero-toggle signals, and we will be changing the functionality in the next release of the software. But first some background. The PowerPlay Power Analyzer's power estimation confidence metric is intended to indicate our confidence in the signal activity information; a power estimate is only as good as the toggle-rate information provided by the user. While the Power Analyzer can guess at what happens on nets based on the activity on other nets in the design, the highest quality power esimates are obtained when all activity is derived by post-fit timing simulations. In Quartus II 5.1, we decided to treat nodes that have a zero toggle rate from simulation the same as nodes for which there is no simulation information at all. The reason is that this could indicate the user didn't fully exercise their design. For example, if you didn't set your reset signal to the right value, nothing in your design would toggle and we'd say we have low confidence. In Quartus II 6.0 (which will be released at the end of April), we are changing this behaviour. We will treat any signal read from simulation to be of good quality, even if it does not toggle. This means you (the user) need to be careful that when parts of your design do not toggle in simulation, you really meant for them not to toggle; Quartus won't warn you about it. But that means designs like yours where circuitry doesn't toggle for a reason will no longer result in a warning. A more common example of this is when a design contains start-up or error-handling circuitry which normally does not do anything. BTW, you can obtain additional information on how Quartus comes up with a confidence metric by looking in the Confidence Metric Details panel of the Power Analyzer report. This report lists the various signal activity sources and how many signals came from each. Regards, Paul Leventis Altera Corp.Article: 98430
I don't have any stats on re-spins and failures (I'm not in that group). But HardCopy II is an ASIC. If the customer makes a mistake in the design and discovers it after tape-out, they have to pay for it. It costs Altera engineering resources to perform the migration, and costs us for the few custom masks needed, and for the production run. We are not a charity :-) The beauty of HardCopy is that we've had quite a few instances of customers who sent us their "final" design, only to let us know moments before tape-out that they'd discovered another bug in their FPGA prototype system. Do these customers get charged for a partial tape-out (we didn't make the masks, but we did do some engineering work)? I don't know. But I'm sure it cost the customer a heck of a lot less than a full ASIC (or structured-ASIC) run + 3 months to market that it would have cost them without the ability to prototype in advance. Regards, Paul Leventis Altera Corp.Article: 98431
The Intel/AMD example is a good one. Sometimes one vendor has the advantage over the other (AMD has one right now). But overall, the two companies basically innovate at a similar rate. Does this mean they are only reaping the benefits of process technology? Does this mean their claims of performance improvements due to innovation are not valid? I'd argue no (well, lets ignore NetBurst for a moment ;-)). All I'm saying is that the average rate of performance increase in FPGAs is much greater than that of the underlying process technology (which I believe was your initial statement). I would not expect a 4:1 advantage from one FPGA vendor to the next; both vendors are innovating at a similar rate per year, with some jumps here and there. I'd argue this with a simple existance proof -- if one company was doing so badly, they would disappear from the market. This has happened in the CPU market and in the FPGA market, where companies that fall behind in innovation fail and disappear. Even the Xilinx vs. Altera epic battle has not been a neck-and-neck race. Xilinx was getting trounced by Altera back in the Flex10K days -- but a combination of innovation and competitor mis-execution got them back into things. Similarly, Altera was starting to fall behind until Stratix & Cyclone came out. If it were easy to make a cost, power and speed competitive FPGA, I'm sure there would be other players in our market (given the profit margins). But it isn't, which is good -- it keeps my job exciting. Regards, Paul Leventis Altera Corp.Article: 98432
I've put together a preliminary slide showing before/after
eye diagram comparisons of the ADS5273 -> V4 interface:
- IBIS/HyperLynx models vs. simple SPICE model
- no back termination vs. 6mA back term + attenuation scheme
Plots are temporarily at the following location until I update the
original file:
ftp://members.aol.com/fpgastuff/temp_plots.pdf
Many thanks to Symon for running those HyperLynx sims for me,
and for reminding me that real world current sources are less
reflective away from midstream than ideal ones .
Setup:
- simple lossless models as originally described in <lvds_current.pdf>
- PRBS-5 data pattern
- note varying scales on plots
Comments:
Again, I'd not trust either method without lab verification;
see notes below for specific concerns, particularly regarding
the DC offset seen on the Xilinx IBIS input models.
In any case, I'd say the plots clearly show the improvement
in ISI crossing jitter and eye closure over the direct connection.
The back terminated version also significantly reduces the
peak-peak reflected junk at the pins of the precision mixed
signal A/D. (bearing in mind real world Tlines have more loss)
The two simulation methods match fairly well, but there's a
smaller eye opening in the SPICE model than in the IBIS plots.
I think they'd match much better without the huge DC offset
in the IBIS models, which seems to be causing the driver to
saturate and/or clamp in the Hyperlynx sims.
This causes the asymmetrical TX overshoot in the lower left
IBIS plots, the imbalance from which then causes the squiggle
in the leading edge of the IBIS Rx crossing waveform.
IBIS model concerns:
- Xilinx v4 IBIS model for LVDS inputs generates IBIS parser
warnings about non-zero clamp currents
- V4 IBIS model pulls up LVDS driver output common mode
from the expected 1.2V to around 1.5V
- DT terminator modeled as simple resistor in IBIS files;
how much does it vary over allowed input range of diff Rx?
Spice model concerns:
- ideal current source model of the driver is perfectly reflective,
unlike an actual device which can't swing past its headroom
- 9 db may be too much with real world Tline loss at weak driver
corner ( reduce attenuation or remove/change 100 ohm back term )
Brian
Article: 98433On 9 Mar 2006 04:31:18 -0800, fpga_toys@yahoo.com wrote: > >manjunath.rg@gmail.com wrote: >> i saw it >> its not of much help..as we are doing it based on subpipelining >> concepts and composite field arithmetic if you find something of such >> sort please do help us > >do you have a C based implemention somewhere as an example? You want to try it in your C -> hardware compiler? I'd be interested in the results. AES is a public algorithm, and widely available. The original proposal (RIJNDAEL) was written in C, and is designed to give good performance on machines that can manipulate 8 bit chunks o' data (e.g. most modern CPUs), so it is a good match to C. http://www.google.com.au/search?q=AES+C http://www.google.com.au/search?q=RIJNDAEL+source+code http://en.wikipedia.org/wiki/Advanced_Encryption_Standard Note that AES is a block cypher. These can be used with or without feedback around the outside. The latency isn't so important when not using feedback, which allows the use of subpipelining to increase the clock rate. Unfortunately, many of the interesting crypto applications use block cyphers with feedback (e.g. CBC, CFB), so the latency affects the throughput, and subpipelining doesn't help. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation Google shows that there are many papers claiming rather fast AES in FPGAs (with some fine print saying they're using a non-feedback mode). I've never seen a feedback mode cypher in a real world application get anything over some Gb/s. Regards, AllanArticle: 98434
Hi everybody, I am beginner in FPGA design ( about 1 year of experience in VHDL design), I enjoy my job but (there is always a but) I think I don't learn a lot of new thing about FPGA since I have been out of my last internship . So why I would like to know which book or website could you recommand me to enhance my knowledge. I' d like to learn about multiple clock domain design, making constraint (not only put a time constraint), interfacing fpga with the 'real wolrd' and all that hint & tips that make the difference betwen a good design and a beginner like me. Thanks you for help! AlexisArticle: 98435
Hallo, I have contacted GRSD team, the Xilinx developers of ll_temac, ll_gemac and multiport memory controller about porting LwIP to ll_temac. They told me that if there is enough demand, they do it, so if someone is interested can post here. Then if we reach sufficient demand I'll contact GRSD team. -- Many Thanks Marco ToschiArticle: 98436
I think the VHDL core is dead. Why MUST it be VHDL? If your tools don't allow a mixed Verilog/VHDL design use a netlist of the core. Works fine for me. Andre mungam wrote: > I have seen that site but the link is broken, only the sources in > verilog are available. > Could you check for me if you caa get the vhdl cores with your PC, > maybe I can't because of my computer. > thank you >Article: 98437
Both FIFOs, and their respective READ_ENABLE signals, are manipulated from within STATE MACHINES (clocked on the rising edge of the respective READ_CLK's). To add another twist to the situation, I have just regenerated the FIFO using Coregen and FIFO GENERATOR v 2.2 (instead of ASYNCHRONOUS FIFO v 6.1), when I simulate the design with this new FIFO both instantiations behave correctly (as expected per the datasheet). Although this solves the problem, it does raise some interesting questions about why the ASYNCHRONOUS FIFO v6.1 simulation model appears to exhibit this strange behaviour. One distinct difference between the two FIFO instantiations is that in the case of FIFO A (the behaviourally correct FIFO) data is written at the faster clock rate and read and the slower clock rate. In the case of FIFO B data is written at the slower clock rate and read at the faster clock rate. Whether this situation highlights a "bug" in the simulation model or not I cannot deduce. Regards, SimonArticle: 98438
Yes I can do it with verilog but I've never read verilog, so i will have to learn it. Did anyone try to use this core before?Article: 98439
Allan Herriman wrote: > You want to try it in your C -> hardware compiler? I'd be interested > in the results. Me too :) I'll take a look at it this weekend, as it might make another interesting example for the next FpgaC release. I have a pipelined RSA-72 I did two years ago when looking at building dnet engines that is a monster because of the barrel shifters and LUT RAMS required for retiming. First glance at the referenced materials suggests the problem with AES is going to be 80 or more block rams for S box lookups tables to get any reasonable parallelism. It's not clear there is an easy way to avoid using sbox tables, as the algorithm for creating the table is itterative. The rest of the requirements per round seem pretty timid. I have a couple ideas to ponder first. The feedback chaining clearly limits performance unless you have a fair number of independent concurrent streams that can be muxed into the pipeline - like a 11 port mux/switch used to breakout a very fast connection.Article: 98440
"JJ" <no@email.please> wrote in message news:dumj7h$dgc$1@panorama.wcss.wroc.pl... > Hi! > > Can't find in help / documentation: where in ISE 8.1 are the options that > decide what language will be used for generation of simulation models and > into what language the testebnch (tbw) file will be translated? > > In ISE 7.1 there was a neat option "Generated Simulation Language" in > project top properties. It's gone in 8.1. Is it necessary to set each > process "Generate Post-Synthesis/Post-Translate/etc. Simulation Model" > individually? Default value in my installation is Verilog, can it be > changed to VHDL? > > And I have no idea how to change test bencher so that for *.tbw file it > generates VHDL (*.vhf) instead of Verilog (*.vf). > > Any help appreciated! > > Jarek > Double click the project name in "Sources for" tree at top left in ISE 8.1. That opens up a properties page that appeared when you created a new project. You can change the simulator and its language from there.Article: 98441
Hi Scott, I can't shed any light on the issue you describe, but... When the SRAM fails to work, does the 'socket' (i.e. the shrinkwrapped IC and PCB etc.) on the end of the JTAG-USB cable get very very hot? Twice now I have had occasions when programming .bit files through one of these cables the end gets very very hot - although everything still seems to work. Due to this and other not quite definable oddities I've switched to programming the platform flash with .svf files and using this to program the FPGA. It doesn't inspire faith in the things... cds Scott M. Kroll (none@nowhere.com) wrote: : Well, I'm not sure if anyone here has had the same problem, but I have, : and it has been driving me nuts. My primary machine is a laptop, which : has no parallel port, so I am stuck with USB. Also, I am in a class : where we are doing projects using the Spartan-3 Starter Kit from Digilent. : Since I have no parallel port, I have been using Digilent's JTAG-USB : cable, which, for the most part, works great. However, there are two : problems. : 1. You cannot use Xilinx IMPACT to program the Spartan-3 : 2. The external SRAM does not work when using a .bit file : Well, #2 seems awfully strange. I know it did for me, I thought I was : having a problem with VHDL, and that's why I thought it wasn't working. : Well, I spent a long time tinkering with it over our winter break (I : know, I know, but it's what I did) and just today I came up with the : solution. : A little explanation for this is probably needed. Basically, anything I : write and compile in IMPACT would work fine. LEDs light up, the : 7-segment display works fine, everything I've done works great. : However, every time I tried to write to the SRAM, nothing changed, I : simply got back garbage/random data. Every time, no questions asked, it : just didn't work. To make a long story short, here's a solution I : discovered (which, is a whole another story to how I figured it out). : 1. Start IMPACT : 2. Edit -> Add Device -> Xilinx Device : 3. Loaded c:\Program Files\Xilinx\spartan3\data\xc3s200_ft256.bsd : 4. Right-Clicked Device, Assigned Configuration File : 5. Mode -> File Mode : 6. Clicked SVF-STAPL-XSVF tab, clicked "Yes" when it asked to load from : Boundary Scan : 7. Chose to generate a new SVF file, named it : 8. Right-Clicked Device, chose Program. : 9. Output -> SVF -> Stop Writing to SVF File : 10. Quit Impact : 11. Started Export, did Device Scan, loaded SVF into the xc3s200, set : the prom to bypass, hit program. Everything worked right. : Seems like a strange solution, but what I want to know, has anyone here : had a problem like this? I have a feeling that loading a different .BSD : file for other Xilinx chips should work just as well with the JTAG-USB : cable/Digilent's ExPort software, but I couldn't tell you. : Hope this helps people out. : If anyone wants to contact me with any more information via email, : please use: skroll at gmail dot comArticle: 98442
Hello and thanks for your attention Data bus signals, address bus signals, Micro(MPC 860) 50MHz clock, some other clocks like (retiming clocks, 19.44 Mhz clocks) are some of the other signals routed in our CPLD. I can not change my pin assignment, because the zl_1944_clk comes into CPLD only from only GCK0 pin. What I should do to make ISE consider zl_1944_clk as a global signal? (I would be grateful if possible for you to provide me with a phone number to speak to you)Article: 98443
> > Google shows that there are many papers claiming rather fast AES in > FPGAs (with some fine print saying they're using a non-feedback mode). > I've never seen a feedback mode cypher in a real world application get > anything over some Gb/s. > > Regards, > Allan Hi Allan, interesting point, but have you thought about what the reasons may be? Let's do some (approximative) calculations. Assume you have a single AES-Round that runs with a 100MHz Clock. This round needs at least 10 clocks to produce an AES Cipher. With 128 Bits Data width that gives: 128 * 100e6 /10 = 1,28e9 Bits per second So that is the limit for the assumed circuit. Adding a feedback path for block cipher modes will extend the number of clocs to create a ciper. Let's assume 14 clocks to produce a CBC cipher Now we have: 128 * 100e6 /14 = 914,3e6 Bits per second That's all what's possible with the assumed circuit. How can we increase the throughput? 1) Wait for better silicon that allows higher clock rates. 2) Use more chip-space to implement aditional rounds and decrease the number of iterations needed in the round. But that may be rather expensive! 3) Improve the rounds latency. Make it fast to the limit. (Which is at about 500MHz as some vendors claim for their products ;-) ) Now let's assume our circuit will still run at 100MHz, but the improved round runs at 500 MHz. That will reduce the round latency to 2 100MHz cycles. Which gives 6 cycles to create the CBC cipher. Now we have: 128 * 100e6 /6 = 2,1e9 Bits per second So, that's the theoretical limit for the assumed circuit. You can exceed it by investing in additional or better (ASIC) silicon, if you have the money. As I understand the original posting, these guys want to spend some work on solution 3 somehow. My tip to manjunath & co.: Have a look at the standard implementations and the book "The design of rijndael" ISBN: 3540425802 Identify the modules and start optimizing the designs to whatever your goal is. Have a nice synthesis EilertArticle: 98444
You can use the DCM architecture wizard to calculate the CLKFX jitter. The number in ps is correct and ignore the number in UI. HTH, Jim (jimwu88NOOOSPAM@yahoo.com remove capital letters) "RobJ" <rsefton@abc.net> wrote in message news:tKYPf.9561$e1.2509@tornado.socal.rr.com... > The data sheet refers you to the Xilinx web site, but I can't find anything > there for Virtex-4. Does the Virtex-II CLKFX jitter calculator also work for > Virtex-4? > > Thanks, > Rob > >Article: 98445
The command to start GUI is "ise" . You can creat an icon yourself and set the command line to "ise". I would just open a terminal window and type the command manually. HTH, Jim (jimwu88NOOOSPAM@yahoo.com remove capital letters) "mikelinyoho" <mikelinyoho@gmail.com> wrote in message news:1141906611.207484.243340@j52g2000cwj.googlegroups.com... > regards: > > since xilinx ise 8.1i support linux red hat 4.0 (with device Spartan-3 > 400k) > After I install xilinx ise 8.1 under linux red hat 4.0,I cannot find a > icon > to start the software "xilinx ise 8.1i".Someone say that I might start > xilinx ise 8.1i at linux red hat 4.0 command mode.Is this saying right? > and how can I achieve that "start xilinx ise 8.1i at linux red hat 4.0" > > any positive suggestions is welcome. > > thank you > best regards to you all >Article: 98446
Our Raggedstone1 product when used with the optional PCI I/O header (reuses PCI interface) gives 50 5V tolerant I/O. Price is £60 / US$108 (ex VAT - if applying) as a special offer currently if you join our newsletter list. £5 more if you don't. Worldwide shipping is £10. We also have a new module coming that will give 5V tolerant I/O from our DIl Headers if you want to run the card as a PCI card rather than just stand alone. Otherwise you can add your own stripboard with resistors as otherwise described. John Adair Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development Board. http://www.enterpoint.co.ukArticle: 98447
I'm using the core in a wishbone environment and it seem to work fine,
haven't done too much testing though. It is not well documented, but you
can get a SJA1000 datasheet from Philips, that helps a lot. Get the
source from CVS, afaik they are more up to date.
Unless you want to make changes to the core some very basic verilog
skills are enough. Here's my component declaration for the wishbone variant:
component can_top
port (
wb_clk_i : in std_logic;
wb_rst_i : in std_logic;
wb_dat_i : in std_logic_vector(7 downto 0);
wb_dat_o : out std_logic_vector(7 downto 0);
wb_cyc_i : in std_logic;
wb_stb_i : in std_logic;
wb_we_i : in std_logic;
wb_adr_i : in std_logic_vector(7 downto 0);
wb_ack_o : out std_logic;
clk_i : in std_logic;
rx_i : in std_logic;
tx_o : out std_logic;
bus_off_on : out std_logic;
irq_on : out std_logic;
clkout_o : out std_logic
);
end component;
mungam wrote:
> Yes I can do it with verilog but I've never read verilog, so i will
> have to learn it.
> Did anyone try to use this core before?
>
Article: 98448Hello Andre, Thank you very much for your answer, you seem to be very well up to date on this topic. I have download the verilog sources from opencores and the compilation was successfull. If I understand well, this core is used to do the same work as the sja 1000 (at the beginning I though that I had to use the sja 1000 too) . I only have to buy a can transceiver to connect the fpga board to the can bus, right? I talked with Igor who wrote this core. He said to me that I have to make a wishbone/pci, but i don't understand quite well how it works. I'm reading about it, I understood that it was use to link different components but that's all untill now. I will also have to link the fpga to the can transceiver, that's another dilema :) Please tell me if i'm wrong and if you have some explanation about the pci wishbone, they are of course welcomed. Thank you AdrienArticle: 98449
mungam wrote: > Hello Andre, > Thank you very much for your answer, you seem to be very well up to > date on this topic. > I have download the verilog sources from opencores and the compilation > was successfull. > If I understand well, this core is used to do the same work as the sja > 1000 (at the beginning I though that I had to use the sja 1000 too) . I > only have to buy a can transceiver to connect the fpga board to the can > bus, right? > I talked with Igor who wrote this core. He said to me that I have to > make a wishbone/pci, but i don't understand quite well how it works. > I'm reading about it, I understood that it was use to link different > components but that's all untill now. > I will also have to link the fpga to the can transceiver, that's > another dilema :) > Please tell me if i'm wrong and if you have some explanation about the > pci wishbone, they are of course welcomed. > > Thank you > > Adrien > Hi Adrien, Maybe this is already clear to you, my apologies if so, but the CAN protocol block and the PCI bridge are both peripherals which are connected to the wishbone bus. Typically there will be a bus master such as a micro-processor core (or equivalent state machine) which will drive the bus to set-up the slave peripherals, monitor the status registers of the slaves, identify when some data needs to be moved from one to the other, and perform the move or configure a DMA bus peripheral to do the move. So your project is not simply a case of connecting the CAN block to the PCI block, you will also need a controller of some sort sitting on the bus (micro-processor core etc). Not a trivial project, but not impossible either by any means. Alan
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