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
Brad Smallridge wrote: > Can anyone tell me what I need to drive a Camera Link > output directly from a V4? I have tried LVCMOS25 and I > can see differential signals at the outputs but at the > end of a 2 meter cable I see only DC differential levels > as if the signals are dampened somehow. > > Brad Smallridge > aivision I think the Camera Link requires a LVDS I/O standard. You may find the following link useful - http://www.alacron.com/downloads/vncl98076xz/CameraLink20v113.pdf Hope this helps.Article: 111001
bart schrieb: > Chris wrote: > > Nope won't work. I talked to Lattice today. There is no internal osc to > > use, and they did not recommend using a bunch of gates. Moreover there is > > no extra flash space either - zip. This is not the first time. Overall I > > am very disappointed with what they put out in their MachXO and XP NV > > families. They lack a lot of little features that would make them so much > > more powerful. I guess they have heard that from others too, he told me > > that they were coming out with a 'revised' new XP line next year. XP-II I > > think he said. > > > > Chris. > > Hello Chris, > > I spoke with our Director of Applications, Bertrand Leigh on this topic > and confirmed that the application will work. > > Antti is correct, you CAN build an internal ring oscillator based on > stacked inverters for a coarse frequency oscillator inside the XP or > EC/ECP type devices. This is a proven method that has worked at > Lattice and at other users. XO and ECP2/M device families have built-in > oscillator based on the configuration oscillator that is accessable > from the FPGA fabric after configuration. > > For Flash write back both options are available -- PERSISTENT=ON for > sysConfig port and through JTAG. > > We will follow up with the person you spoke to on our technical support > line and let them know about this application. Sorry if they caused any > confusion. > > Hope this helps. > Bart Borosky, Lattice Semiconductor thanks Bart, there are many ways to make a ring-oscillator, depends on the needs I have one version that I call fgpa_safe it is basd on 4 FF that use only set reset pins. This thing always delivers an "useable" clock for given FPGA and works any synthesis tool, eg does not get optimized away. there can different other methods, which may be better but may require special trick to fool the optimizer and may require LOC contraints to get better repeated frequency. invertor chain may run too high simetimes, as example for V4 special care has to be taken to get the inverter chain frequency to be low enough to be useable. in most cases the fgpa_safe oscillator is sufficient, is sure has large difference in frequency as it will be routed by different paths each time. AnttiArticle: 111002
> Any other suggestions? I believe The MPMC2 zip has two projects using 16-bit memory: v4fx12lc_ddr_idpp_100mhz v4fx12mm_ddr_idpp_100mhz I found this info in the release notes... Take a look at these cores... /MikhailArticle: 111003
see http://www.digilentinc.com/Products/Detail.cfm?Prod=S3E1600&Nav1=Products&Nav2=ProgrammableArticle: 111004
Ah, I see. The functionality is supported through ioctl() and struct ibm_gpio_ioctl_data. A little strange, but okay.Article: 111005
Hi Richard, You can set the "DSP Block Balancing" synthesis setting to "Logic Elements". In the QSF, it looks like this: set_global_assignment -name DSP_BLOCK_BALANCING "LOGIC ELEMENTS". That should prevent DSP blocks from being used. Hope this helps, Subroto Datta Altera Corp. On Oct 26, 12:04 am, "rnbrady" <rnbr...@gmail.com> wrote: > Hi > > I'm compiling my design using Quartus II and using a Cylclone II EP2C35 > device. The fitter reports currently says it's using 34 /70 embedded > 9-bit multiplier blocks. I'd like to see how much extra logic it uses > if I tell it not to use the embedded multipliers, but I can't seem to > turn them off. > > Under the synthesis settings I can set "maximum DSP block usage" from > -1 to 0 but this has no effect. Any tips? > > Thanks, > RichardArticle: 111006
<rponsard@gmail.com> wrote in message news:1161898879.404939.234850@b28g2000cwb.googlegroups.com... > see > http://www.digilentinc.com/Products/Detail.cfm?Prod=S3E1600&Nav1=Products&Nav2=Programmable Woo Hoo ! _And_ it apparantly has Stepping 1 silicon. Thanks for the heads-up.Article: 111007
> I think the Camera Link requires a LVDS I/O standard. > > You may find the following link useful - > http://www.alacron.com/downloads/vncl98076xz/CameraLink20v113.pdf > Lattice has a reference design available for this 7:1 source synchronous LVDS interface (also known as Channel Link, Flat Link, and Camera Link). Lattice's 7:1 LVDS Video Interface Reference Design has been optimized for use with the LatticeECP2/M family of FPGAs. The reference design implements standard 7:1 LVDS interfaces using the LatticeECP2/M I/O structure. Transmit and receive interfaces are fully and efficiently implemented by specifically taking advantage of dedicated LVDS I/O, the generic DDR I/O interface, 2x gearing, and PLL clocking of edge and system clocks. The entire design has been tested using a 7:1 LVDS Display Demo system at speeds of 595MHz. Detailed Information about the Reference Design and source code is available here: http://www.latticesemi.com/products/intellectualproperty/referencedesigns/71lvdsvideointerfaceforec.cfm Hope this helps. Bart Borosky, LatticeArticle: 111008
"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message
news:1161885433.411222.205690@m73g2000cwd.googlegroups.com...
>
> Hi Mike,
> It has nothing to do with compile order.
Based on what I've seen on this thread it appears to me that it probably
does have to do with the compile order.
> My son is not an vhdl writer,
> but knows many thing unregular. He just happend to get the thing done
> right, many times I asked for his help and he got things done.
>
> I tried following several options without success:
> 1. Put textio.vhd in the project top position;
> 2. Compile all by clicking manu icon;
> 3. Compile by clicking manu icon with textio.vhd selected;
>
> My son put textio.vhd at the last position in project file list, select
> textio.vhd, then clicked manu compile/compile-selected and compiled
> textio.vhd only. After that he compiled all files and succeeded.
>
> If the compile position is concerned, his position is wrong, because
> textio.vhd would be called before all files, but he did it.
My earlier suggestion was a band-aid since it appeared that 'something' had
recreated textio for you and done so using the wrong style ('87).
The problem though seems to have to do with the 'bram64_512' module that is
in your current project since earlier in the thread you said that after
deleting the textio from the library it reappeared after compiling
'bram64_512'. This would imply that 'bram64_512' is creating it's own
version of the textio package that is at the root of what you're fighting.
The problem that you need to hunt down is what exactly what source file(s)
in your project is(are) creating textio (and why?) and then why is it
compiling it '87 syntax. The way to attack that is to clean textio out of
the library and then compile each file in your project one at a time. Do
this for each since for all you know textio might be in more than one of
your source files. The other way would be to do a text search through each
source file and find where the package is being created....but if the
project list is relatively short, clicking to compile and then looking at
the library result works too.
KJ
Article: 111009
KJ wrote:
> The problem though seems to have to do with the 'bram64_512' module that is
> in your current project since earlier in the thread you said that after
> deleting the textio from the library it reappeared after compiling
> 'bram64_512'. This would imply that 'bram64_512' is creating it's own
> version of the textio package that is at the root of what you're fighting.
I have just added an item to my list of
advantages to inferring block ram from a
code template :)
-- Mike Treseler
Article: 111010
KJ wrote:
> "Weng Tianxiang" <wtxwtx@gmail.com> wrote in message
> news:1161885433.411222.205690@m73g2000cwd.googlegroups.com...
> >
> > Hi Mike,
> > It has nothing to do with compile order.
> Based on what I've seen on this thread it appears to me that it probably
> does have to do with the compile order.
>
> > My son is not an vhdl writer,
> > but knows many thing unregular. He just happend to get the thing done
> > right, many times I asked for his help and he got things done.
> >
> > I tried following several options without success:
> > 1. Put textio.vhd in the project top position;
> > 2. Compile all by clicking manu icon;
> > 3. Compile by clicking manu icon with textio.vhd selected;
> >
> > My son put textio.vhd at the last position in project file list, select
> > textio.vhd, then clicked manu compile/compile-selected and compiled
> > textio.vhd only. After that he compiled all files and succeeded.
> >
> > If the compile position is concerned, his position is wrong, because
> > textio.vhd would be called before all files, but he did it.
>
> My earlier suggestion was a band-aid since it appeared that 'something' had
> recreated textio for you and done so using the wrong style ('87).
>
> The problem though seems to have to do with the 'bram64_512' module that is
> in your current project since earlier in the thread you said that after
> deleting the textio from the library it reappeared after compiling
> 'bram64_512'. This would imply that 'bram64_512' is creating it's own
> version of the textio package that is at the root of what you're fighting.
>
> The problem that you need to hunt down is what exactly what source file(s)
> in your project is(are) creating textio (and why?) and then why is it
> compiling it '87 syntax. The way to attack that is to clean textio out of
> the library and then compile each file in your project one at a time. Do
> this for each since for all you know textio might be in more than one of
> your source files. The other way would be to do a text search through each
> source file and find where the package is being created....but if the
> project list is relatively short, clicking to compile and then looking at
> the library result works too.
>
> KJ
Hi KJ,
I have two files written by myself containing textio.vhd file.
All other blocks, like bram64_512 module, are generated by Xilinx
CoreGenerator and their vhdl files don't contain explicitly
'std.textio.all;'
When I first changed my two files to include write() and writeline()
functions, everything went well. Suddenly one day textio.vhd problem
burst from blue.
Your suggestion is of valuable. My son finished the last touch to
finish the job.
Thank you.
Weng
Article: 111011Mike Treseler wrote: > KJ wrote: > > > The problem though seems to have to do with the 'bram64_512' module that is > > in your current project since earlier in the thread you said that after > > deleting the textio from the library it reappeared after compiling > > 'bram64_512'. This would imply that 'bram64_512' is creating it's own > > version of the textio package that is at the root of what you're fighting. > > I have just added an item to my list of > advantages to inferring block ram from a > code template :) > > -- Mike Treseler Hi Mike, How do you infer a block ram? I would like to learn the technique. Thank you. WengArticle: 111012
Brad,
The V4 should have no trouble whatsoever driving a 2m camera link (3M MDR
type) cable. I currently have a design using a V2PRO30 that drives 5m of
cable. The differential pins are driven by the below module.
Take care,
Rob
module diff_outbuf_single(in, p_out, n_out);
input in;
output p_out;
output n_out;
OBUFDS inst1 (
.O(p_out), // Diff_p output(connect directly to top-level port)
.OB(n_out), // Diff_n output (connect directly to top-level port)
.I(in) // Buffer input
);
endmodule
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:12k1op3ddh0iea@corp.supernews.com...
> Can anyone tell me what I need to drive a Camera Link
> output directly from a V4? I have tried LVCMOS25 and I
> can see differential signals at the outputs but at the
> end of a 2 meter cable I see only DC differential levels
> as if the signals are dampened somehow.
>
> Brad Smallridge
> aivision
>
>
Article: 111013rponsard@gmail.com wrote: > is that a known bug ? > > ISE 8.2 / win XP seems to freeze while synthesing design (no more mouse > or menu/button action event response... looks like a threading bug) > > at the end of computation, it comes back to normal execution. > If it completes the operation, its a feature, not a bug. Many, or even MOST windows apps don't multithread their user interface. In fact, Windows isn't particularly good at it, there are known issues with two threads trying to access the GUI at once. Scott MooreArticle: 111014
I quit. A brand new project, with only a dcm, a debug module, 16K ram, an uart and intc will not work (problems writing BRAM). Will continue using 8.1 for a long time, I suspectArticle: 111015
Hi Helen,
Helen schrieb:
> Many thanks for your input! Yes you are right, compout is driven
> outside the FPGA and is not synchronous. I have tried out your
> suggestion (see below), and it does definitely improve things (removes
> most of the jumps :-), but I still have something going wrong as there
> are still some occasional jumps in the data. I have staggered the
> integrator sum to a falling edge of the clock. (see below). Is this
> what you meant by 2-stage shift register?
No *g*
> Is there anything else I can
> try?
Yes.
Two stage shift register means two FF in serial clocking in the signal
with your clock and you use the 2nd register. This should do for most
cases, but could be improved by using 3 FF (as below).
process (Clk, Rst)
signal Compout_Reg_Sr : std_ulogic_vector(2 downto 0); -- shift
if Rst=RESET_ACTIVE then
Compout_Sr <= (others => '0'); -- all bits to '0'
elsif Rising_edge(Clk) then
Compout_Sr <= Compout_Sr(1 downto 0) & Compout;
if Compout_Sr(2)='1' then
-- do something
end if;
end if;
This helps you eliminating effects of metastability (should be no
problem for a 8MHz clk anyway), and allows you to have stable signal
crossings between two timing domains.
You should use such technique for every asynchronous signal when
changeing clock domains.
bye Thomas
Article: 111016Hi all, I'm currently developing a PCB featuring a Xilinx Virtex-4 device. Unlinke the Virtex-II series they now offer the possibility to route various clock signals to several domains on the FPGA and select them locally by specific clock multiplexer inputs. Because of the restricted amount of available pins on the device I selected (Virtex-4 FX40 with 352 user I/Os) I would like to use just one clock input on each side of the FPGA, thereby saving clock multiplexer inputs which I can use as normal GPIOs, and use an external clock multiplexer instead for my 3 clocks. Has anyone made experience with such or similar solution? Has anyone used an external clock multiplexer device for frequencies up to 500 MHz, yet? Is there any recommendation which chip I could use for this application in terms of jitter, etc.? And by the way... is my approach advisable, at all? Any comments are appreciated. Regards ElmoArticle: 111017
Zara schrieb: > I quit. > > A brand new project, with only a dcm, a debug module, 16K ram, an uart > and intc will not work (problems writing BRAM). > > Will continue using 8.1 for a long time, I suspect quit? your life? EDK 8.2 does work I have done maybe over 50 EDK systems with 8.2 - all of them work if your system doesnt there is something wrong and you should figure out what it is, not quitting. AnttiArticle: 111018
Thanks Thomas - I will try this!Article: 111019
On 27 Oct 2006 00:18:43 -0700, "Antti" <Antti.Lukats@xilant.com> wrote: >Zara schrieb: > >> I quit. >> >> A brand new project, with only a dcm, a debug module, 16K ram, an uart >> and intc will not work (problems writing BRAM). >> >> Will continue using 8.1 for a long time, I suspect > >quit? your life? > >EDK 8.2 does work >I have done maybe over 50 EDK systems with 8.2 >- all of them work > >if your system doesnt there is something wrong >and you should figure out what it is, not quitting. > >Antti No, it was a figure of speech. Whta I really mean is that I will stop investigation while I am completing the current phase of my project. As soon as some 40something boarsd are delivered; I will resume trying. As a sapnish adage goes "Last to be lost is Hope" ;-) Regards, ZaraArticle: 111020
I have flashpro-lite programmer of actel. But, in use, very
uncomportable because i don't know how to solve the error..... Any one
have the error books?
This is the errors i faced...
programmer 'FPL31LPT1' : Scan Chain...
Error: programmer 'FPL31LPT1' : Signal Integrity Failure
Integrity Check Pattern Not Found.
Integrity Check Pattern :
550FAAF000FF0000FFFF
IrScan Error.
TDO stuck at 0
Chain Analysis Failed.
Error: programmer 'FPL31LPT1' : Data Bit length : 8272
Error: programmer 'FPL31LPT1' : Compare Data :
0000............................00000
Error: programmer 'FPL31LPT1' : Scan Chain FAILED.
Error: Failed to run programming.
Well.... Do you know what is the problem and solution? Plz, let me know
your experiences...
Article: 111021Elmo Fuchs wrote: > Hi all, > > I'm currently developing a PCB featuring a Xilinx Virtex-4 device. Unlinke > the Virtex-II series they now offer the possibility to route various clock > signals to several domains on the FPGA and select them locally by specific > clock multiplexer inputs. > Because of the restricted amount of available pins on the device I selected > (Virtex-4 FX40 with 352 user I/Os) I would like to use just one clock input > on each side of the FPGA, thereby saving clock multiplexer inputs which I > can use as normal GPIOs, and use an external clock multiplexer instead for > my 3 clocks. > Has anyone made experience with such or similar solution? Has anyone used an > external clock multiplexer device for frequencies up to 500 MHz, yet? Is > there any recommendation which chip I could use for this application in > terms of jitter, etc.? And by the way... is my approach advisable, at all? > > Any comments are appreciated. > > Regards Elmo What I find amazing is that you feel the need to sacrifice a chip's normal clock architecture just for the sake of gaining a few more I/O pins. If you are so tight on your design fit that you are approaching nearly 100% I/O utilization on the FPGA then you better begin looking at another approach. First off let me describe the issues of designing to the limit of a part. It is always wise to reserve some number of I/O pins on a design. These are needed for several very important reasons. One is the need to allow for some additional expansion in case you discover the need for bring a bit more of the outside world in or to bring out some controls for other devices or logic. With new designs it is very often that even with the best design intentions one can end up overlooking the need for additional stimulous going in or status coming out. Second there the the huge benefit of having some extra I/Os on test points that you can temporarily connect into internal parts of the FPGA circuit to support the debug and design validation process. Big FPGAs with lots of complex embedded circuitry can be a challenge to debug and the visibility pins will be a godsend if and when you need them. Lastly there is a common habit formed by FPGAs that once you lock the pins and commit to the PC board connectivity subsequent changing of the internal logic definition in a big way can sometimes make it next to impossible to keep the same pin allocation. A few spare pins on each side or within each I/O block of the chip can often allow a re-fit to work if you free one or two I/Os from their previously locked pins. When considering how to move away from a design that is targeting nearly 100% utilization you can consider a number of approaches. Look at partitioning the design in a manner that you could put it into pair of smaller devices. On the other hand there is also the possibility to move to a larger FPGA device as well. A third thing to look at is if a considerable number of I/O pins can be saved by using some simple fixed logic devices at the periphery of the chip. A simple example is the parallel to serial conversion strategy that could be implemented with cheap shift registers to support many slow GPIOs with a few I/O pins at the FPGA. It is relatively easy to design FPGA logic that can free run a shift in or shift out process to keep the external GPIO states in synch with internal nodes with a modest latency. Good Luck - mkarasArticle: 111022
kypilop wrote: > I have flashpro-lite programmer of actel. But, in use, very > uncomportable because i don't know how to solve the error..... Any one > have the error books? > This is the errors i faced... > > programmer 'FPL31LPT1' : Scan Chain... > Error: programmer 'FPL31LPT1' : Signal Integrity Failure > Integrity Check Pattern Not Found. > Integrity Check Pattern : > 550FAAF000FF0000FFFF > IrScan Error. > TDO stuck at 0 > Chain Analysis Failed. > Error: programmer 'FPL31LPT1' : Data Bit length : 8272 > Error: programmer 'FPL31LPT1' : Compare Data : > 0000............................00000 > Error: programmer 'FPL31LPT1' : Scan Chain FAILED. > Error: Failed to run programming. > > Well.... Do you know what is the problem and solution? Plz, let me know > your experiences... > I've had similar symptoms with Flashpro (not -Lite) when the APA was dead or when there was a physical disconnect on the board between the Flashpro header and the JTAG pins on the APA (error in pcb schematic). Can you try another board?Article: 111023
> Antti is correct, you CAN build an internal ring oscillator based on > stacked inverters for a coarse frequency oscillator inside the XP or > EC/ECP type devices. This is a proven method that has worked at > Lattice and at other users. XO and ECP2/M device families have built-in > oscillator based on the configuration oscillator that is accessable > from the FPGA fabric after configuration. Yes I saw that the XO does have an internal osc. That is good. But the XO2280 has 1/3 the RAM as the 3E-100. Not sure the XO2280 has enough to do what I need. I need 32bit wide True Dual Port. That burns up 2 banks. The 3E-100 only needs one bank. Not sure I can get the instruc space that I need using a Micro8 on the XO2280. I can run 3 PicoBlaze on the 3E-100 no problem. > For Flash write back both options are available -- PERSISTENT=ON for > sysConfig port and through JTAG. Yes that is what I thought too, but what good is it since the local FAE told me there is no spare flash space. If there is spare flash area for user data, please let me know. The datasheet gives little info on this. Thanks, Chris.Article: 111024
Zara wrote > As a sapnish adage goes "Last to be lost is Hope" ;-) It's Pandora. When she opened the box all the misfortunes of mankind flew out, leaving only Hope. Of course, you can argue that hope (9.1?) is the worst of all evils ;-)
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