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 all, we are trying to implement a QAM 64 system using the altera stratix gx for a project. all of us are new to fpga's, so pardon our ignorance. i had a couple of questions about the device capabilities. 1) we are looking at purchasing a low cost evaluation board http://www.hitechglobal.com/PLDA/pciedk.htm) that does not come w/ any design software. can we just use the free web edition of quartus and/or dspbuilder for programming the device, or do we need to buy a license for the full version. 2) does the quartus software/dspbuilder have capabilites to implement serial-parallel. i know i can just use a shift register for a 1-2 serial parallel. but does it have any functions for 1-3 serial-parallel(splitting an input stream into 3 parts) 3) is it possible to work w/ multilevel signals and assign specific voltages (something betn output swing of the device) to each level. for instance, -1.2V to 000, -0.9V to 001 and so on. we are trying to use this setup to implement a simple 3 bit DAC. thanks in advance, kaaliaArticle: 87651
Hey all, I just made a V4 pcb and wanted to configure the FPGA through impact => this works fine, so it says that the done pin goes high and everything is ok but the code will not run because the GHIGH_B stays low ... but when i configure the fpga through chipscope everything works, the GHIGH_B goes high and the vhdl is working ... how come??? i thought they both used the same process/dll/program to configure the fpga?? i think it has something to do with the properties of the impact program ... thanks in advance, kind regards, Tim VerstraeteArticle: 87652
"Tim Verstraete" <tim.verstraete@barco.com> schrieb im Newsbeitrag news:AeQFe.155026$F25.8316022@phobos.telenet-ops.be... > Hey all, > > I just made a V4 pcb and wanted to configure the FPGA through impact => this > works fine, so it says that the done pin goes high and everything is ok but > the code will not run because the GHIGH_B stays low ... but when i configure > the fpga through chipscope everything works, the GHIGH_B goes high and the > vhdl is working ... how come??? > > i thought they both used the same process/dll/program to configure the > fpga?? i think it has something to do with the properties of the impact > program ... > > thanks in advance, > > kind regards, > > Tim Verstraete > > No. The configuration has been a problem at all times there is always some combination of software and cables that work and some that do not. Some times impact works and chipscope not. Sometimes chipscope does and impact not. sometimes cable IV does not work and self made cable does. etc etc etc. A complete mess. for V4 check the early silicon errata about JTAG maybe it applies to your chip, I think not but who knows. Hm what V4 are you using? I can add support for it into our JTAG frequence meter application, it includes config support for V4, then you could see if our software works better than impact. in the current public online version I think only LX25 is supported but we could easily add your FPGA device to the supported list just to see if it would configure AnttiArticle: 87653
Pablo, Powering ON is a simple, yet tough thing to do well. We simulate ramps, and ramps with dips, and other things, and we test with ramps, but we can't and don't simulate for every possible power supply made. Thus, the typical power ON specification wants to see a "monotonic" rise. In the strictest sense, this means that the slope is always the same sign (never stops rising). Will it work if there is a plateau? Will it work with a slight dip? Generally, yes. But if you call, and say it does not work with your ABC power supply, and that supply is not monotonic, we can say "sorry, but we warned you that it doesn't work with every possible power supply in the universe." If you use a power supply that does not comply (for example, all of our listed power partners DO comply), then it is up to you to characterize your board, and be sure it will work with all possible variations of your powering solution. Austin Pablo Alvarez Sanchez wrote: > Hi, > > If you read the specs of the XCFxxP PROMs, you find: > > http://www.xilinx.com/bvdocs/publications/ds123.pdf (page 22 of 42) > > "At power up, the device requires the VCCINT power supply > > to monotonically rise to the nominal operating voltage within > > the specified VCCINT rise time." > > > > Is monotonicity in VCCINT so important for the XCFxxP PROMs? Why? (I > understand monotonicity= positive slope) , > > or the only important thing is that the oe/reset line is released once > VCCINT is stable? > > Cheers > > > > Pablo AlvarezArticle: 87654
I have a top level design with a clock
this clock goes into an into a DCM
and then into a submodule where the dcm divided clock is monitored
with a process statement. and is used with a rising_edge(clk) statement
as well
yet ISE (XST) still tells me there is no input clock signal
what the heck is going on?
do i need to change some synthesis settings?
please help
code below:
library ieee;
use ieee.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
use ieee.numeric_std.all;
-- synthesis translate_off
library UNISIM;
use UNISIM.VCOMPONENTS.all;
-- synthesis translate_on
library XilinxCoreLib;
-- V2P has 198 KB of BRAM
--roughly 50,000 double words
entity system is
port (
OPB_Clk : in std_logic; --driven by 100mhz clk
SYS_RESET : in std_logic;
-- all these are big endian
A : out std_logic_vector(0 to 31); --A, OE, WE, D are shared flash
& sram
OE_L : out std_logic;
--WE_L : buffer std_logic;
WE_L : out std_logic;
D : inout std_logic_vector(0 to 31);
SRAM_CS_L : inout std_logic;
SRAM_BS_L : out std_logic_vector(0 to 3); -- "bs" signals control
"BLE#" and "BHE#"
TRGT_IRQ : in std_logic;
SYS_ACE_CS_N : out std_logic; -- data buffer enable
GPIO_CS_N : out std_logic -- data buffer enable
);
end system;
architecture structural of system is
component IBUFG
port
(
O : out std_ulogic;
I : in std_ulogic
);
end component;
component DCM_INST
port
(
CLKIN_IN : in std_logic;
RST_IN : in std_logic;
CLKDV_OUT : out std_logic;
CLKIN_IBUFG_OUT : out std_logic;
CLK0_OUT : out std_logic;
LOCKED_OUT : out std_logic
);
end component;
component BUFG
port(
O : out std_ulogic;
I : in std_ulogic
);
end component;
-- internal block ram to store read data
-- must convert to little endian when plugging in address
component sub_sys is
port
(
clk : in std_logic; --driven by 100mhz clk
A : out std_logic_vector(0 to 31); --A,
OE, WE, D are shared flash & sram
D : inout std_logic_vector(0 to 31);
TRGT_IRQ : in std_logic
);
end component;
--------------------------------------------------------------------------------
-- internal signals
--------------------------------------------------------------------------------
signal opb_clk_int : std_logic;
signal clk_div_buf : std_logic;
signal opb_clk_buf : std_logic;
signal dcm_clk0_buf : std_logic;
signal locked : std_logic;
signal dcm_clk0 : std_logic;
signal dcm_clkdv : std_logic;
begin
--------------------------------------------------------------------------------
-- instantiations
--------------------------------------------------------------------------------
sub_system : sub_sys
port map
(
clk => clk_div_buf,
A => A,
D => D,
TRGT_IRQ => TRGT_IRQ
);
buffered_100 : BUFG
port map
(
I => DCM_CLK0,
O => DCM_CLK0_BUF
);
buffered_50 : BUFG
port map
(
I => DCM_CLKDV,
O => clk_div_buf --DCM_CLKDV_BUF
);
Inst_DCM_INST : DCM_INST port map
(
CLKIN_IN => OPB_Clk,
RST_IN => SYS_RESET,
CLKDV_OUT => DCM_CLKDV,
CLKIN_IBUFG_OUT => opb_clk_int,
CLK0_OUT => DCM_CLK0,
LOCKED_OUT => locked
);
SYS_ACE_CS_N <= '1'; --disable data buffer when system
ace is not used
GPIO_CS_N <= '1'; --to prevent the buffer from driving
the bus (B -> A)
WE_L <= '1';
OE_L <= '1';
SRAM_BS_L(0 to 3) <= "1111";
SRAM_CS_L <= '1';
end architecture;
--
Geoffrey Wall
Masters Student in Electrical/Computer Engineering
Florida State University, FAMU/FSU College of Engineering
wallge@eng.fsu.edu
Cell Phone:
850.339.4157
ECE Machine Intelligence Lab
http://www.eng.fsu.edu/mil
MIL Office Phone:
850.410.6145
Center for Applied Vision and Imaging Science
http://cavis.fsu.edu/
CAVIS Office Phone:
850.645.2257
Article: 87655Hi: I have been tasked to build several custom laboratory instruments. One is a "safety system" for some engine combustion research labs that prevents the "engine controller" computer (a PC with a DIO board implementing a word generator driven by a shaft encoder on the engine) from issuing attempts to fire the engine for too long or at bad timings. This safety system has been delayed for several years due to other priorities. The engine controller that we have now has problems with signal integrity and so its "patch panel" (the panel that buffers the DIO board signals to BNC connectors for connection to lab stuff) needs to be redone. Additionally, the engine controller runs on MS-DOS, and so I'd like to update it to a modern architecture. Trouble is, this really isn't necessary because "if it works don't fix it." There are also no capabilities desired that it doesn't do already. However, the engine controller does need to be connected to various SRS and Berkeley Nucleonics delay generator boxes for generating pulses in the time domain, as the engine controller only works in the shaft encoder's angular domain. In summary then: 1. Need a safety system. 2. Need a new version of the engine controller patch panel. 3. Would like but don't need a new engine controller. 4. A future engine controller upgrade would be even better if it incorporated the safety system and time-domain delay generators. I have decided that the logic required to implement the safety system (uses an absolute encoder to check timings against the quadrature encoder that drives the engine controller computer) is complicated enough that it should be based on a large CPLD or small FPGA. But if I base it on an FPGA, then it is only some additional HDL to implement the engine controller functions anyway. So why not just make an engine controller with integrated safety features? That's where I am heading. One missing link: The time domain delay generators. Some stuff needs only microsecond resolution, so my present elementary logic skills can design those. But there are also nanosecond and 100ps resolution delays which we employ for some laser timing/intensified camera gating situations. It is my understanding that an FPGA with DLLs and other clock timing/phasing features can be set up to give much finer resolution delays than could be achieved merely by counters at it's max clock rate. But the methods employed to do this and even an understanding of the finer clock management features of modern FPGAs are way beyond me. (I have just about mastered the much simpler world of CPLDs). So my plan here is to think ahead. I want to design in an FPGA that is approachable with my present skills, but with enough surplus resources that I can expand the initial functionality (the safety system) into a full-blown engine controller with delay generators at a later time. What FPGA architecture should I employ to implement a gadget which can do what I want (engine controller and safety system) while leaving a considerable amount of free logic resources for future advancement of its capabilities into the realm of delay generation to ns and sub-ns resolution? I am looking at Spartan 3 development boards now. The Virtex stuff just seems way too overkill. There is no way I'd ever touch a million gates. But a few 10s of thousands or even a 200k FPGA might be suitable. Would like to stick with Xilinx. I know my logic demands are vaguely specified at this point. The idea is to get a rough idea of whether incorporating the fine resolution delays is worth planning for or not. Thanks for comments. Good day! -- _______________________________________________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarleRemoveThis@BOGUSsandia.gov NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.Article: 87656
Its one clock tick.......My clock is 27Mhz..... ThanksArticle: 87657
Geoffrey, What's inside DCM_INST? Could you try connecting a CLK0 output of a DCM (after BUFG) to CLKIN input of a DCM as well? VladislavArticle: 87658
Teo wrote: > I think it would be easiest to use Abel for a Gal device. You can find > examples undert c:/ispTools/examples/spld/gal > > Alternatively you could also just use a 32 m/c device like a 4032v and > do a schematic. Cost would likely be just a little more. > > Teo Do you know if the ABEL flows also work on the new MachXO ? -jgArticle: 87659
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag news:42e7e6d4$1@clear.net.nz... > Teo wrote: > > > I think it would be easiest to use Abel for a Gal device. You can find > > examples undert c:/ispTools/examples/spld/gal > > > > Alternatively you could also just use a 32 m/c device like a 4032v and > > do a schematic. Cost would likely be just a little more. > > > > Teo > > Do you know if the ABEL flows also work on the new MachXO ? > -jg > > Hi jg, to my understanding, NO ! just for you I created a test project in ispLEVER SP1 with Sch/Abel as toplevel and machXO can not be selected as target. when sch/VHDL is toplevel then I can select machXO OK, so I assume the abel flow is not supported for XO unless there is hidden backdoor to enable it. AnttiArticle: 87660
Hey folks,
OK, I'm feeling a little silly here. I'm trying to use a dual port ram in
a xilinx v2p device, and I'm having problems reading data back from the ram.
Using modelsim, I can see that my data is getting written to the ram, but I
never see the data on the ram's output port during read cycles.
I'm writing data into the ram at one clock rate, and reading at another.
The idea is wen goes high, and I fill up the ram with a sequence of data.
Then after a few cycles, wen goes low, and the data is read out at a slower
rate to eventually get sent to the PPC and out a serial port. Am I mising
something in my code? I've included it below, following the language
templates in ISE.
module example_ram (wclk, rclk, din, dout, waddr, raddr, wen);
input wclk;
input rclk;
input wen;
input [8:0]waddr;
input [8:0]raddr;
input [31:0]din;
output [31:0]dout;
// dual port capture ram
RAMB16_S36_S36 ram_0 (
.DOA(), // Port A 32-bit Data Output
.DOB(dout[31:0]), // Port B 32-bit Data Output
.DOPA(), // Port A 4-bit Parity Output
.DOPB(), // Port B 4-bit Parity Output
.ADDRA(waddr[8:0]), // Port A 9-bit Address Input
.ADDRB(raddr[8:0]), // Port B 9-bit Address Input
.CLKA(wclk), // Port A Clock
.CLKB(rclk), // Port B Clock
.DIA(din[31:0]), // Port A 32-bit Data Input
.DIB(), // Port B 32-bit Data Input
.DIPA(), // Port A 4-bit parity Input
.DIPB(), // Port-B 4-bit parity Input
.ENA(1'b1), // Port A RAM Enable Input
.ENB(1'b1), // PortB RAM Enable Input
.SSRA(1'b0), // Port A Synchronous Set/Reset Input
.SSRB(1'b0), // Port B Synchronous Set/Reset Input
.WEA(wen), // Port A Write Enable Input
.WEB(1'b0) // Port B Write Enable Input
);
endmodule
Thanks,
-- Matt
Article: 87661see comments below "Chris Carlen" <crcarleRemoveThis@BOGUSsandia.gov> schrieb im Newsbeitrag news:dc8kj00fvm@news3.newsguy.com... > Hi: > > I have been tasked to build several custom laboratory instruments. One > is a "safety system" for some engine combustion research labs that > prevents the "engine controller" computer (a PC with a DIO board > implementing a word generator driven by a shaft encoder on the engine) > from issuing attempts to fire the engine for too long or at bad timings. > This safety system has been delayed for several years due to other > priorities. > > The engine controller that we have now has problems with signal > integrity and so its "patch panel" (the panel that buffers the DIO board > signals to BNC connectors for connection to lab stuff) needs to be redone. > > Additionally, the engine controller runs on MS-DOS, and so I'd like to > update it to a modern architecture. Trouble is, this really isn't > necessary because "if it works don't fix it." There are also no > capabilities desired that it doesn't do already. > > However, the engine controller does need to be connected to various SRS > and Berkeley Nucleonics delay generator boxes for generating pulses in > the time domain, as the engine controller only works in the shaft > encoder's angular domain. > > In summary then: > > 1. Need a safety system. > 2. Need a new version of the engine controller patch panel. > 3. Would like but don't need a new engine controller. > 4. A future engine controller upgrade would be even better if it > incorporated the safety system and time-domain delay generators. > > I have decided that the logic required to implement the safety system > (uses an absolute encoder to check timings against the quadrature > encoder that drives the engine controller computer) is complicated > enough that it should be based on a large CPLD or small FPGA. But if I > base it on an FPGA, then it is only some additional HDL to implement the > engine controller functions anyway. > > So why not just make an engine controller with integrated safety features? > > That's where I am heading. > > One missing link: The time domain delay generators. Some stuff needs > only microsecond resolution, so my present elementary logic skills can > design those. But there are also nanosecond and 100ps resolution delays > which we employ for some laser timing/intensified camera gating situations. this may be a hard nut depending on the actual requirements > It is my understanding that an FPGA with DLLs and other clock > timing/phasing features can be set up to give much finer resolution > delays than could be achieved merely by counters at it's max clock rate. > But the methods employed to do this and even an understanding of the > finer clock management features of modern FPGAs are way beyond me. (I > have just about mastered the much simpler world of CPLDs). DCM phase adjust step may be very small around 50-60ps ? but there could be jitter of 300ps so depending on your requirement the DCM may or may not useable option > So my plan here is to think ahead. I want to design in an FPGA that is > approachable with my present skills, but with enough surplus resources > that I can expand the initial functionality (the safety system) into a > full-blown engine controller with delay generators at a later time. > > What FPGA architecture should I employ to implement a gadget which can > do what I want (engine controller and safety system) while leaving a > considerable amount of free logic resources for future advancement of > its capabilities into the realm of delay generation to ns and sub-ns > resolution? > > I am looking at Spartan 3 development boards now. The Virtex stuff just > seems way too overkill. There is no way I'd ever touch a million gates. > But a few 10s of thousands or even a 200k FPGA might be suitable. as you are not targetting 'low low lowest price high volume product' but rather 'mission critical, all performance may come handy, single unit price not so impartant' then, well the overkill may actually come handy. I understand that the 'overleft' 1M+ gates look like too heavy overkill, but there are other features in V4 that are not there is low cost spartan-3, and it looks like those features may be needed in your case. 1) V4 has ability to runtime reconfigure the DCM parameters, the phase delay can be adjusted in S3 too, but V4 DCM can be fully reprogrammed whild FPGA working 2) V4 fabric is WAY faster. The LUT logic propagation delay is many time smaller than in S3. This may as well be needed. 3) there are some other 'adjustable' delay options for IO, etc, and other architecture enhancements, which as well could be come to use. So to be on the safe side I would suggest low-end V4 > Would like to stick with Xilinx. > > I know my logic demands are vaguely specified at this point. The idea > is to get a rough idea of whether incorporating the fine resolution > delays is worth planning for or not. > yes, from your specs it is not possible to give 100% assurance that some FPGA would do all the things you mentioned, eg this 100ps accurate delays. It would be possible to make delay gen with 100ps tuning step. hmm sounds like fun task. V4 fabric can switch at 1GHz so that gives 1ns resolution, with some more tricks the 100ps step could be achived as well. But I would not try that in S3, S3 fabric goes fancy below 500MHz already. > Thanks for comments. > > Good day!Article: 87662
Peter K. wrote: > Rune Allnor wrote: > > > > If it could be truly demonstrated that, for this particular company, > > > that approach worked... why not? > > > > It's about proepr use of manpower. Manually, the post-experiment > > data organization work takes 3-6 months, prior to any analysis. > > Most of it is drudgery. Automize that to take, say, 1 - 2 weeks, > > and the crew is free to do interesting or even useful stuff. > > And you can cut project time and cost with ridiculous amounts. > > Definitely! > > Show management the $ different between 3-6 months and 1-2 weeks, and > you'll have your case sown up (they'll be begging you to do it!). > > > Some see the ISO 900x stuff as added bueracracy. It may well be, > > but it might also be a very powerful tool to streamline the > > production, if used wisely. > > I was involved in a small company that needed ISO9001-2000 > accreditation to be considered as a supplier for a major company. The > company was a start-up and we had complete freedom (within the > constraints of ISO9001) to write our own procedures. > > What we did was to figure out what we were doing (and why we were doing > it), look at some "best practices" to see if we should be doing > anything else, and wrote that down as our quality manual. > > Because we had the luxury of defining it ourselves, and because we > involved as many people as possible in the discussion about it, we had > really good buy-in and understanding of why the process was necessary. > > Heck, we even passed ISO accredition first time with only the minimum > allowable set of data (I think it was 3 months). Brilliant. > My biggest reason for getting the system in place was for clarity of > communicaiton: among team members, between teams, between team leaders > and upper management, between our company and suppliers, between our > company and customers. Yeah, those are the exact reasons why I am positive to ISO 900x. RuneArticle: 87663
Hi Kaalia, The Stratix GX series are pretty support-intensive. For the questions you asked, I would say that you would need to speak to your local disti or Altera FAE. Off the cuff, the answers to your questions are: 1 - No, you need a full version of Quartus, _plus_ an additional feature line that you need to request from Altera or your local distributor. 2 - not natively, but of course you can cobble it together using DSP Builder macros or some custom VHDL or Verilog. 3 - No. _Especially_ not with negative voltages. Use a DAC. Best regards, BenArticle: 87664
Sounds like you can do all the engine control and safety stuff in the fpga at a modest clock rate, 10 or 20 MHz maybe. An external dumb-logic watchdog or two might be a good idea, too. You could use an SRS or BNC delay generator for just the camera stuff, since you have those already. I know of no obvious way to get decent ps-resolution delays from an FPGA alone. We make a small OEM delay generator that's Spartan3-based, 50 MHz clock, but we use external analog stuff for the fine delays... http://www.highlandtechnology.com/DSS/T560DS.html JohnArticle: 87665
You can get "picosecond" pulses out of the Mult-Gigabit transceivers in Virtex-IIPro and Virtex-4FX. At 3 Gbps one data bit = 333 ps, at 6 Gbps it's 156 ps, and when you push it to 10 Gbps, it's 100 ps. So you can modulate an outgoing data stream with that kind of resolution. For example, you can generate a 1 MHz signal with 200 ps adjustment accuracy, which is one part in 5,000. And all of this with crystal-frequency accuracy. Peter Alfke, Xilinx ApplicationsArticle: 87666
Methi, you have received many suggestions from this group. Perhaps it is time to tell us which ones you have tried or are going to try. It seems to me that the original title of this thread has become meaningless. You can fit your design many times over into the quoted device... Peter Alfke, Xilinx ApplicationsArticle: 87667
Hi, Is there a way to pass parameter to "do file" in the command line in vsim? Intuitively, it will be something like this usr@host>vsim tb_dm -c -do mysim.do 1144 (the 1144 is the parameter to be passed into mysim.do) but it doesn't work...Article: 87668
"Peter K." <p.kootsookos@iolfree.ie> writes: > Randy Yates wrote: > >> >> I'll see you and Peter in the marketplace. >> > > Is that a threat or a promise? Or both? > > :-) It's a fact. -- % Randy Yates % "Maybe one day I'll feel her cold embrace, %% Fuquay-Varina, NC % and kiss her interface, %%% 919-577-9882 % til then, I'll leave her alone." %%%% <yates@ieee.org> % 'Yours Truly, 2095', *Time*, ELO http://home.earthlink.net/~yatescrArticle: 87669
If you're using 7.1.03i, you may want to take a look at AR 21694: http://tinyurl.com/atxwr Jim "Tim Verstraete" <tim.verstraete@barco.com> wrote in message news:AeQFe.155026$F25.8316022@phobos.telenet-ops.be... > Hey all, > > I just made a V4 pcb and wanted to configure the FPGA through impact => this > works fine, so it says that the done pin goes high and everything is ok but > the code will not run because the GHIGH_B stays low ... but when i configure > the fpga through chipscope everything works, the GHIGH_B goes high and the > vhdl is working ... how come??? > > i thought they both used the same process/dll/program to configure the > fpga?? i think it has something to do with the properties of the impact > program ... > > thanks in advance, > > kind regards, > > Tim Verstraete > >Article: 87670
Hi Junaid, Quartus can output blif, and can read & synthesize verilog. So it can act as a verilog to blif converter. Quartus can either output "raw gates" blif before any optimization has occured, or it can output a blif netlist of the circuit technology-mapped to k-input-LUTs after all optimization of the logic has occured. The upcoming release (for use with Quartus II 5.0) of the Quartus University Interface Program materials includes detailed documentation on exactly how to output blif from Quartus, as well as many other things: sample benchmark circuits, XML descriptions of Altera's FPGAs that can be used to write place and route tools targeting them, even a way to output Verilog from SIS so you can bring circuits from SIS back into Quartus for further analysis or verification. See http://www.altera.com/education/univ/quip/quip-overview.html for details. Version 5.0 hasn't been posted yet, but it should be very soon. Transfering data from Quartus to SIS (and vice versa), including blif output from Quartus, is described in the documents/quip_synthesis_interface.pdf file in QUIP 5.0. Until QUIP 5.0 is on the web, here is a quick overview of how to generate blif from Verilog: To generate un-optimized (raw gates) blif, add the following to your <projectname.qsf> file: set_global_assignment -name INI_VARS "no_add_opts=on; opt_dont_use_mac=on; dump_blif_before_optimize=on" Then run quartus_map <projectname> The blif output will be in <projectname>.blif If you want a blif output of the circuit after the logic has been optimized and technology mapped to LUTs and FFs, use this settings line instead of the one above: set_global_assignment -name INI_VARS "no_add_opts=on; opt_dont_use_mac=on; dump_blif_after_lut_map=on" There are some limitations on what circuits can be output to a blif netlist, since blif is not as general as Verilog. See QUIP 5.0 for details. Regards, Vaughn Altera [v b e t z (at) altera.com] "junaid" <k.najeeb@gmail.com> wrote in message news:1122026304.657790.4750@g14g2000cwa.googlegroups.com... > Hi All, > > Can anyone suggest a method to convert verilog file into blif (LUT) > format. Does altera or xilinx support this file conversion ?. Kindly > help me in this regard > > Thanking you in advance >Article: 87671
Peter Alfke wrote: [...] > And all of this with crystal-frequency accuracy. > Peter (and Austin), Speaking of crystal-frequency accuracy, you reminded me of a question I've had for a little while. How much can the CLKIN input to a DCM vary before you have to worry about it losing lock? Assume the output drive a GBUF, which feeds directly back to the CLKFB. I know Austin answered this type of question at least once before (http://groups.google.com/groups?q=ppm+dcm+input), but I don't see in the V2Pro, V4, or S3 datasheets where the 100 ppm is spec'ed. Is the spec still the same for the above parts? Thank you, MarcArticle: 87672
Hi guys, The Quartus error message is correct. The I/O cell (on the FPGA die) which implements the positive I/O of LVDS channel 13 is bonded out to Pin F5 on the EP2C8F256. However, the I/O cell which implements the negative I/O of the LVDS channel 13 differential pair is not bonded out on this package. I am not sure of the precise reason -- there are many goals and restrictions when a package pin-out is chosen. The effect is that you cannot use LVDS channel 13 in the EP2C8F256. Pin F5 is usable for non-LVDS purposes (i.e. as a general I/O). The EP2C8Q208 has both the negative and positive I/O cells of LVDS channel 13 bonded out, so LVDS channel 13 is usable in that device/package combo. Regards, Vaughn Altera [v b e t z (at) altera.com] "Ben Twijnstra" <btwijnstra@gmail.com> wrote in message news:2a222$42e7a6a2$d55db008$28922@news.chello.nl... > Hi Thomas, > >>> file what & where ? >>> Ah, support request ? That is this personal login stuff ? > > Yep. > >>> A black hole, IMO. > > Not entirely. I have over 300 SRs on my account since 2000 that have been > fixed by now. Most of them even within an agreeable timeframe. I will not > make any further quantitative or qualitative remarks about Altera's > support > service - it sort of works for me. > > Anyway, I filed SR#10507655 with the following text regarding version 1.3 > of > the EP2C8 pin table: > > ==== Cut here ==== > For the EP2C8, in the F256 package, on page 1, pin F5 is listed as > LVDS13p. > However, there is no corresponding LVDS13n for this package. > > If I assign signal zort2 to pin F5 using LVDS as an IO standard, Quartus > II > 5.0SP1 reports the following: > > Error: Can't place node positive with differential I/O zort2 in location > (0,17,2) -- location does not support differential pin pair functionality > Error: Can't place I/O pin zort2(n) in non-bonded location PAD_7 > Error: Can't fit design in device > > Can you add a remark for the F256 package about this? > ==== Cut here ==== > > Let's see what happens... > > Best regards, > > > Ben >Article: 87673
Hi Rick, The correct email for address changes is mysupport_cs@altera.com. Regards, Vaughn Altera [v b e t z (at) altera.com] "Jedi" <me@aol.com> wrote in message news:f6vFe.264$%U5.258@read3.inet.fi... > Antti Lukats wrote: >> "Jedi" <me@aol.com> schrieb im Newsbeitrag >> news:i74Fe.125$Sg3.58@read3.inet.fi... >> >>>Jedi wrote: >>> >>>>Moro >>>> >>>>Back from a successful trip in .ch I have to change >>>>my contact details at Altera and they provide >>>>an email address for doing this: >>>> >>>> csecom@altera.com >>>> >>>>which just leads into nirvana and bounces back >>>>with "user unknown"... >>>> >>>>Any other address to use? Or why is it not allowed to >>>>change address online? >>> >>>I guess nobody at Altera discovered this or don't care? >>> >>> >>>rick >> >> >> they dont care >> > > And all Altera guys seem to be on vacation for several weeks now... > as well as their webmasternot knowning that csecom@altera.com > results in "unknown user"... > > Looks like I have to fly to Finland from Switzerland every time a new > NIOS/Quartus upgarde is out (o; > > > rick >Article: 87674
Hi everyone,
I have a VHDL file which I use it in EDK in one of my
custom cores ..I also have a netlist file which has been generated
using JHDL . The netlist file is in EDIF format. So now i want to
import this netlist file in my VHDL so that I can connect to the JHDL
component .I dunno if this is actually feasible to do . In case anyone
has done this sort of stuff ..Help me out guys!!
Thanks in advance
--
Parag
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