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, I sythesised (with Xilinx ISE) some complex logic circuit just consisting of AND and XOR gates and I am wondering if there is any way I can identify in the post-sythese report the depth of the circuit in number of gates, ie. the number of logical gates that make up the critical path. Would be great if somebody could me help me out with this one! RichardArticle: 152026
You can just do this with the Microblaze processor. Just read the value from memory, do what you want with it and then write it back. If you need to do it faster than this then you would need to write a custom IP block to interface with the PLB bus that could read and write from memory. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152027
On Thu, 23 Jun 2011 06:31:33 -0700, Richard wrote: > Hi all, > > I sythesised (with Xilinx ISE) some complex logic circuit just > consisting of AND and XOR gates and I am wondering if there is any way I > can identify in the post-sythese report the depth of the circuit in > number of gates, ie. the number of logical gates that make up the > critical path. > > Would be great if somebody could me help me out with this one! > > Richard Run the timing analyser. After synthesis it will use estimated timings; after place and route it will use accurate timings derived from the routing. It will give details of the logic depth ( in LUTs rather than gates ) of the slowest n paths, according to the options you use to run it. - BrianArticle: 152028
On Jun 23, 4:38=A0am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > When simulating my back annoted design with modelsim, I get unexpected > > behavior when using a simulation step of 1ns, but no errors when using > > a step of 1ps. > > Do you need to do back annotated simulation? > > If a functional simulation works, the design is properly constrained and = is > passing static timing analysis then I'd expect it to work solidly. > > ? > > Nial. This is probably worthy of its own thread, but here goes. Gate-level sim does do its part in verifying the translation of RTL into gates, a phase in the EDA flow not covered by funct sim or STA. There are a number of things that can go wrong down the physical path, from quirky RTL coding that doesn't get synthesized as intended (e.g. inferred latches) to inconsistencies in core (rams, fifos, dsp units, clock managers, etc.) configurations. Having said that, gate-level sim is slow and painful and hard to bring up, and many designers elect not to do it unless there is a compelling reason, such as strange lab results. Even then, one might cook up a chipscope session and perhaps focus on RTL vs. gate schematics to isolate the fault. I personally depended on it for years for all initial spins, then didn't bother for subsequent code mods because I was confident that I had already verified the physical translation. Since I've been using the same proven HDL and core integration methodologies for years, I'm confident enough not to spend the time for gate-level sim (and delay time to market even further). Maybe this goes without saying, but should a designer elect not to go down the gate-level sim path, that designer should pay close attention to all warnings that are logged by the synthesis and par tools. The goal should be to eliminate those warnings if possible. The tools have become very adept at recognizing any questionable design practices. - JohnArticle: 152029
> Run the timing analyser. After synthesis it will use estimated timings;
> after place and route it will use accurate timings derived from the
> routing.
>
> It will give details of the logic depth ( in LUTs rather than gates ) of
> the slowest n paths, according to the options you use to run it.
Cheers Brian, I did what you suggested with the following simple
boolean circuit:
library ieee;
use ieee.std_logic_1164.all;
entity test is
port
(
a : in std_logic;
b : in std_logic;
c : in std_logic;
d : out std_logic
);
end test;
architecture struct of test is
signal t : std_logic;
begin
t <= a and b;
d <= c xor t;
end struct;
Of course you would expect here to see somewhere a logical depth of
two logic gates, (or in LUTS one LUT should do the trick).
However, when I check the timing report I get the following
information:
INFO:Timing:2698 - No timing constraints found, doing default
enumeration.
INFO:Timing:2752 - To get complete path coverage, use the
unconstrained paths
option. All paths that are not constrained will be reported in
the
unconstrained paths section(s) of the report.
INFO:Timing:3339 - The clock-to-out numbers in this timing report are
based on
a 50 Ohm transmission line loading model. For the details of this
model,
and for more information on accounting for different loading
conditions,
please see the device datasheet.
Data Sheet report:
-----------------
All values displayed in nanoseconds (ns)
Pad to Pad
---------------+---------------+---------+
Source Pad |Destination Pad| Delay |
---------------+---------------+---------+
a |d | 4.374|
b |d | 4.221|
c |d | 4.162|
---------------+---------------+---------+
Analysis completed
Are there any parameters I have to pass to XST so that it analysis the
logical path in number of LUTS?
Thanks once again!
Article: 152030
> Run the timing analyser. After synthesis it will use estimated timings;
> after place and route it will use accurate timings derived from the
> routing.
>
> It will give details of the logic depth ( in LUTs rather than gates ) of
> the slowest n paths, according to the options you use to run it.
Cheers Brian. I wrote a very simple logical circuit consisting of two
gates just to try these
things out:
entity test is
port
(
a : in std_logic;
b : in std_logic;
c : in std_logic;
d : out std_logic
);
end test;
architecture struct of test is
signal t : std_logic;
begin
t <= a and b;
d <= c xor t;
end struct;
After the place & route I check the timings and get the following
details.
INFO:Timing:2698 - No timing constraints found, doing default
enumeration.
INFO:Timing:2752 - To get complete path coverage, use the
unconstrained paths
option. All paths that are not constrained will be reported in
the
unconstrained paths section(s) of the report.
INFO:Timing:3339 - The clock-to-out numbers in this timing report are
based on
a 50 Ohm transmission line loading model.
Data Sheet report:
-----------------
All values displayed in nanoseconds (ns)
Pad to Pad
---------------+---------------+---------+
Source Pad |Destination Pad| Delay |
---------------+---------------+---------+
a |d | 4.374|
b |d | 4.221|
c |d | 4.162|
---------------+---------------+---------+
Analysis completed
Unfortuantely, nothing is mentioned of how deep the circuit is which
should be one LUT I guess. Anyone
an idea what I am missing?
Cheers!
Article: 152031> This is probably worthy of its own thread, but here goes. Gate-level > sim does do its part in verifying the translation of RTL into gates, a > phase in the EDA flow not covered by funct sim or STA. There are a > number of things that can go wrong down the physical path, from quirky > RTL coding that doesn't get synthesized as intended (e.g. inferred > latches) to inconsistencies in core (rams, fifos, dsp units, clock > managers, etc.) configurations. At some point you have to trust the tools. > I personally depended on it for years for all initial spins, then > didn't bother for subsequent code mods because I was confident that I > had already verified the physical translation. Since I've been using > the same proven HDL and core integration methodologies for years, I'm > confident enough not to spend the time for gate-level sim (and delay > time to market even further). I haven't done a gate-level sim for 15 odd years (showing my age) when the group in which I was working (Nortel, Belfast) decided it was a waste of time. I later worked in Nortel Harlow then Agilent in South Queensferry (both big professional, experienced R&D groups) and AFAIK no-body was doing this as a matter of practice. I don't think I've ever seen an instance where the synthesised and P&R'd results didn't match with what I was expecting. Having written this I'm probably going to get stung on my next project! > Maybe this goes without saying, but should a designer elect not to go > down the gate-level sim path, that designer should pay close attention > to all warnings that are logged by the synthesis and par tools. The > goal should be to eliminate those warnings if possible. The tools have > become very adept at recognizing any questionable design practices. Indeed. Nial.Article: 152032
On Jun 22, 9:45=A0am, "chifalcon" <eric.he@n_o_s_p_a_m.n_o_s_p_a_m.hotmail.com> wrote: > Hi, > =A0 I need to modify the netlist generated from "Generate Post-map simula= tion > model"(i.e. netgen). > > =A0 After the netlist modifcation, can I continue the work of place&route > based on the modified simulation model netlist? > > =A0 Thanks! > > =A0 Eric > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Long answer: You can't Place & Route a *simulation* netlist, before or after modification.Article: 152033
On Jun 23, 7:29=A0am, Richard <sportfre...@gmx.at> wrote: > > Run the timing analyser. After synthesis it will use estimated timings; > > after place and route it will use accurate timings derived from the > > routing. > > > It will give details of the logic depth ( in LUTs rather than gates ) o= f > > the slowest n paths, according to the options you use to run it. > > Cheers Brian, I did what you suggested with the following simple > boolean circuit: > > library ieee; > use ieee.std_logic_1164.all; > entity test is > port > ( > =A0 a : in std_logic; > =A0 b : in std_logic; > =A0 c : in std_logic; > =A0 d : out std_logic > ); > end test; > > architecture struct of test is > > =A0 signal t : std_logic; > > begin > > =A0 t <=3D a and b; > =A0 d <=3D c xor t; > > end struct; > > Of course you would expect here to see somewhere a logical depth of > two logic gates, (or in LUTS one LUT should do the trick). > However, when I check the timing report I get the following > information: > > =A0INFO:Timing:2698 - No timing constraints found, doing default > enumeration. > =A0INFO:Timing:2752 - To get complete path coverage, use the > unconstrained paths > =A0 =A0 option. All paths that are not constrained will be reported in > the > =A0 =A0 unconstrained paths section(s) of the report. > =A0INFO:Timing:3339 - The clock-to-out numbers in this timing report are > based on > =A0 =A0 a 50 Ohm transmission line loading model. =A0For the details of t= his > model, > =A0 =A0 and for more information on accounting for different loading > conditions, > =A0 =A0 please see the device datasheet. > > =A0Data Sheet report: > =A0----------------- > =A0All values displayed in nanoseconds (ns) > > =A0Pad to Pad > =A0---------------+---------------+---------+ > =A0Source Pad =A0 =A0 |Destination Pad| =A0Delay =A0| > =A0---------------+---------------+---------+ > =A0a =A0 =A0 =A0 =A0 =A0 =A0 =A0|d =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A04.= 374| > =A0b =A0 =A0 =A0 =A0 =A0 =A0 =A0|d =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A04.= 221| > =A0c =A0 =A0 =A0 =A0 =A0 =A0 =A0|d =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A04.= 162| > =A0---------------+---------------+---------+ > > =A0Analysis completed > > Are there any parameters I have to pass to XST so that it analysis the > logical path in number of LUTS? > > Thanks once again! IMHO, the best way to do this is to add a clock to your design, register the inputs and register the outputs and then place a PERIOD constraint on the clock in your UCF file. This will provide a more accurate number for your experimentation avoiding extra delays caused by the input and output buffers. You will likely need to turn on the Verbose reporting feature in the timing analyzer so that paths are reported even when the timing constraint is met. Ed McGettigan -- Xilinx Inc.Article: 152034
On Jun 23, 10:40=A0am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > At some point you have to trust the tools. > Maybe to a certain extent. There are many instances where I think it's actually a good practice NOT to trust the tools so much. The hardware designer who wants to reap the benefit of using a "high-level descriptive langauge" by quickly patching together some code using wide comparators and counters while liberally sprinkling his code with "x", "+", and "-" operators--then expects to press the button and get the tools to run at 300+ MHz at 80% capacity inside a large die--is in for a rude awakening. In the end, tools are just that--tools. I hear what you are saying about general design flow. A seasoned designer shouldn't need gate-level sim if he simply heeds the tool warnings. I too have ceased using gate-level sim a while back. But sloppy design practices (there are plenty of novices out there), such as those related to multiple clock domains and async interfaces, can lead to a set of gates that function different than the RTL (and subsequently funct sim). The knowledge that this can happen is golden when trying to isolate such bugs. (Of course, asynchronous vulnerabilities aren't guaranteed to be exposed via gate-level sim-- another argument against using it!) - JohnArticle: 152035
On 23 juin, 10:38, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > When simulating my back annoted design with modelsim, I get unexpected > > behavior when using a simulation step of 1ns, but no errors when using > > a step of 1ps. > > Do you need to do back annotated simulation? > > If a functional simulation works, the design is properly constrained and is > passing static timing analysis then I'd expect it to work solidly. > > ? > > Nial. Well if could avoid post-PAR simulation I would do it. But the thing is that is aeroneautics tools must be assessed. And there is no way vendors will assess their synthesis/P&R tools (if it is even possible). That said, even gate simulation is not sufficient to check the result of P&R as: - Simulator is not assessed and can lead to incorrect simulation (this is sometimes solved by unsing two simulators) - Back annoted design may not reflect programming file content To address those flaws, hardware tests have to be performed but even those might prove wrong (due to tester distraction for exemple) The goal in the aeronotics processes is to secure each step and catch most errors at each level. I hope I might one day avoid gate level sim as it really is a pain but it is still requested by aviation certification authorities.Article: 152036
On Thu, 23 Jun 2011 07:29:31 -0700, Richard wrote: >> Run the timing analyser. After synthesis it will use estimated timings; >> after place and route it will use accurate timings derived from the >> routing. >> >> It will give details of the logic depth ( in LUTs rather than gates ) >> of the slowest n paths, according to the options you use to run it. > > Cheers Brian, I did what you suggested with the following simple boolean > circuit: > Are there any parameters I have to pass to XST so that it analysis the > logical path in number of LUTS? > Sorry, I assumed the context of a more complete circuit. Follow Ed's advice : add a clock, and registers before and after the circuit itself. Add a timing constraint to the clock. Now. An alternative to Ed's suggestion to use verbose reporting from the timing analyzer : reduce the timing constraint period (or increase frequency) until P&R fails. Timing analysis will now give the full and gory details of the worst n paths that failed the timing constraint, including the levels of logic you are after. This is logical and sensible tool behaviour; if it passed timing, most people don't care about the details. But if it failed, seeing the depth of the logic depth will guide you as to what part of the design must be improved to meet timing. (Alternatively, it may show that excessive routing delay comes from poor placement of one or more components. But that is another story) - BrianArticle: 152037
Hi Richard, Xilinx has netgen tool that can help you with that. 1. running netgen on a post-synthesis netlist will create a gate-level HDL representation. For example: $ netgen -w -ofmt verilog -sim <netlist name>.ngc post_synthesis.v 2. running netgen on a post-MAP design file will create a gate-level HDL with placement information. For example: $ netgen -s 3 -pcf <your design name>.pcf -sdf_anno true -sdf_path "netgen/map" -w -dir netgen/map -ofmt verilog -sim <netlist name>.ncd post_map.v 3. running netgen on a post-PAR design file will create a gate-level HDL with placement and routing information. For example: $ netgen -s 3 -pcf <your design name>.pcf -sdf_anno true -sdf_path "netgen/par" -insert_pp_buffers true -w -dir netgen/par -ofmt verilog - sim <netlist name>.ncd post_par.v You can also do it from ISE GUI without using command-line. Thanks, Evgeni ====================== http://outputlogic.com ======================Article: 152038
If it's simply 2 halves of a design with a pipe between them I would use LVDS as the pipe because it can be very predictable latency and you can build that into the combined design as simply something that looks like a normal register pipeline. As soon as you stick something in that adds channel handling messaging, or retransmission of packets, etc. maintaining that fixed latency is much more difficult. If your board design isn't fixed you could add one or two more pairs of LVDS to allow parity, frame sync, or even clock forwarding techniques. The clock forwarding is a good technique because it is simple but also the clock delay at the second chip then tends to track the data variation with temperature, voltage, silicon batch etc.. This avoids all the complication of recovery or syncing of data and you are unlike to need any error detection as once it is setup correctly in the design/board the link probably never fail. John Adair Enterpoint Ltd. - Home of Raggedstone3. The Cyclone-IV GX Development Board. On Jun 15, 3:59=C2=A0pm, Vivek Menon <vivek.meno...@gmail.com> wrote: > I have a design partitioned over 2 FPGAs. I am trying to determine the be= nefits of selecting GTX links vs. LVDS to transfer the data between FPGAs. > > Target Device =C2=A0: xc6vlx550t > Target Package : ff1759 > Target Speed =C2=A0 : -2=EF=BB=BF > > Latency calculations: > 1. GTX interface: The GTX transceiver is configured at 106.25 MHz with 20= bits input. This means the bits are transmitted at bit-rate =3D 20*106.25 = MHz =3D 2.125 Gbps. > # of bits to be transferred =3D 1728 > Latency of this interface =3D 1/(80% of bit-rate * (20/16)*(# of bits=EF= =BB=BF transferred/16)) =3D 1/(2.295+e11) =3D 4.35+e-12 seconds > > 2. LVDS+Aurora: The Aurora interface is configured at 600MHz (6 Gbps) wit= h lane width as 2 bytes. > > Latency of this interface =3D 1/(80% of clock rate * (# of bits=EF=BB=BF = transferred/16)=EF=BB=BF) =3D 1/(5.184+e10) =3D 19.29+e-12 seconds > > Is this calculation correct? My assumption for the LVDS calculation is th= at Aurora does not up-sample the clock frequency by 20 for transmitting dat= a. > > Thanks in advance for all the feedback.Article: 152039
"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> writes: >> This is probably worthy of its own thread, but here goes. Gate-level >> sim does do its part in verifying the translation of RTL into gates, a >> phase in the EDA flow not covered by funct sim or STA. There are a >> number of things that can go wrong down the physical path, from quirky >> RTL coding that doesn't get synthesized as intended (e.g. inferred >> latches) to inconsistencies in core (rams, fifos, dsp units, clock >> managers, etc.) configurations. > > At some point you have to trust the tools. > I'm set up to easily (if time-consumingly) do "gate-level" (post-PAR and post-synth) simulations. They come in handy for first spins, making sure that reset logic works OK, DCMs come up. Also useful for gathering power consumption data. And process is to do them before a "final release", which is fine as it's easy to do. Having said that, the last two "bugs" I've found at the final release stage have been in the *VHDL netlister*. Not my code. Not the synthesis. The netlister - the bit I'm not really wanting to test! Grrr :) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 152040
On 6/24/2011 1:35 AM, Martin Thompson wrote:
> I'm set up to easily (if time-consumingly) do "gate-level" (post-PAR and
> post-synth) simulations.
> And process is to do them before a "final release", which is fine as
> it's easy to do.
Yes, a good check off item for release, but not for the
code, sim, edit, loop.
Gate-level is more a test of the tools than of the design.
> Having said that, the last two "bugs" I've found at the final release
> stage have been in the *VHDL netlister*. Not my code. Not the
> synthesis. The netlister - the bit I'm not really wanting to test!
> Grrr :)
Can also be an error is the sim code or sim configuration.
-- Mike Treseler
Article: 152041I haven't done this in a while. Is it still possible to double click an output in the ModelSim simulator and get a graphical report on all the logic leading up to that output? Brad Smallridge AiVision > I sythesised (with Xilinx ISE) some complex logic circuit just > consisting of AND and XOR gates and I am wondering if there is any way > I can identify in the post-sythese report the depth of the circuit in > number of gates, ie. the number of logical gates that make up the > critical path.Article: 152042
Hi all I need to digitize a 32 channel sensor array, hosed in a pipe of 50mm diameter and 6m length. Sensors are hydrophones integrated with preamplifiers. Simultaneous sampling is required with 20Ksamp/s/ch be the required sampling rate. To further complicate the matter, I need to send digitized data over 1000m quad cable (AWG30) or coaxial cable.One thought was to send digitized data over ethernet format but it had its own problems and limitations (as mentioned in my previous post). Can any one give me the idea how to accomplish this task?The hardware for digitization and data sending needed to be fitted in 50mm dia pipe.I have used cirrus logic CS5368 8 channel ADC IC and with four of these ICs i can digitize whole array but one problem i face is how (and on what format) to send the combine data over 1000m quad/coaxial cable(i have limitations to use repeaters or optical fiber). This will be a prototype designing which if successful will extend to a 128 channel sensor array. Any other soution or idea will be much appreciated. Best Regards --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152043
Mike Treseler <mtreseler@gmail.com> writes: > On 6/24/2011 1:35 AM, Martin Thompson wrote: > >> I'm set up to easily (if time-consumingly) do "gate-level" (post-PAR and >> post-synth) simulations. > >> And process is to do them before a "final release", which is fine as >> it's easy to do. > > Yes, a good check off item for release, but not for the > code, sim, edit, loop. > Absolutely. Fast design loops are the key to productivity (IMHO). > Gate-level is more a test of the tools than of the design. > Agreed. >> Having said that, the last two "bugs" I've found at the final release >> stage have been in the *VHDL netlister*. Not my code. Not the >> synthesis. The netlister - the bit I'm not really wanting to test! >> Grrr :) > > Can also be an error is the sim code or sim configuration. > Indeed it can. One day I hope for it to be so, it's an awful lot easier to fix when it's my code :) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 152044
On 22 Jun., 18:03, KJ <kkjenni...@sbcglobal.net> wrote: > On Jun 22, 5:21=A0am, Thomas Stanka <usenet_nospam_va...@stanka-web.de> > wrote: > > > I would not expect any vendor to give a minimum timescal explicit, but > > you need to use a decent resolution when simulating in order to get > > correct results. This is some basic of engineering, > > You're probably being overly harsh on JB as well as being guilty of > the same thing that you say he is lax on. =A0After all, what is your > definition of 'decent resolution' if you yourself don't expect a > vendor to give you minimum timescale...which they did by the way in > this case by telling JB the method to determine that timescale. Im don't mean to be harsh. We do a lot of simplifications when simulating. Whenever something goes wrong you should start asking yourself if you could justify all simplifcations you did. After checking that you did all right you should ask if other did something wrong. regards ThomasArticle: 152045
On 5/5/2011 12:58 PM, saar drimer wrote: > In a bit of a self promotional move, though probably pretty relevant > to this group, I'd like to mention [snip] As a reminder and a caution for future posting: http://www.faqs.org/faqs/usenet/advertising/how-to/part1/ which reminded me why your post didn't get much of a feedback even though I found the content rather interesting. > for easing the migration from GUI to command-line use of FPGA tools, > and more effective project/build management. I want to say that I'm on your side when you say that a "command-line" use of FPGA tools is a nice to have, but I have to admit that the overall tendency is to use GUI and integrated environments where the designer has the (deceived) perception that everything is at his own hand and control. We can argue a lifetime on what is better, but IMHO the market has chosen its horse and is not the command-line, regardless efficiency drawbacks. The portability problem is often used as an argument to propose yet another model that will have eventually the same problems of portability that previous models had. That is why I always intend portability in the sense that is easy to carry around for it doesn't depend on system's features or device's features and ultimately tool's features. In addition I believe most of the designers out there are not really moving from a linux machine to a windows machine every day and they don't switch from an ABC device to a CBA device every other day and whenever they would be in the place where they *have to* switch, it's going to be a hard day and no magic can be at hand but a previously thought through approach to design in an as abstract way as possible. Hardware Description Languages have been invented for good because they give the designer a mean which will help him looking at the big picture instead of the gates and flops actually used. And this level of abstraction has an enormous potential that most of the time is overlooked in the names of concepts like "optimization" or "I had to put that GCLK buffer otherwise it wouldn't work!". > > The project is at an early stage, and more features will be added with > time. Praise, constructive feedback, and well-mannered bashing are > welcome, of course... be as honest as this group knows how to be (feel > free to email me privately as well). Finally, I'm looking for early > adopter projects, and offer my help with the setup. Talking about scalability problems, how do you intend to provide help on the long run? Say you have 10 million users instead of 10, I think numbers do play a difference. On top of it, what make your company different from yet another EDA company willing for designers to adopt their approach and strangle them with incompatibility features that will shackle them for the rest of their life? Since is not open-source and is profit oriented, do you think it's enough to say that your approach "is better" to convince designers to change their habits? After all a designer wants to design as much as a painter wants to paint. If art can be made with any tool available in your garage, hardware can follow the same line and be built with just an editor or any available tool you have in your computer (maybe a text editor is enough!). That is why IMHO we should foster good designing approaches that will enhance the portability in terms of code, as opposed to project structure. The project approach is borrowed from the management world and has nothing to do with HDL. Indeed I always asked myself why should I create a project when my goal is to describe how a piece of hardware should work. "Project" is a name poorly defined, a concept poorly defined, with no boundaries and no constraints and that is the root of all your and our problems. > > Thanks for your attention, Believe me, even though I might have sounded harsh, I paid a lot of attention to it! > saar. > >Article: 152046
Because your sensor array length is only 6m, you shouldn't get problems with sampling strobe skew. Is this eventually going to be a production system? If so about how many? The reason that I ask is that if both are one-offs, the component cost is less important than for a production system, but the design cost and risk are more important. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152047
It was all going so well until I asked XST to compile a VHDL entity with a generic of this type: type video_modes_e is (vesa_1024x768_65Hz); I guess I'll have more modes later, but just now I need only the one. But as soon as I put a generic of type video_modes_e on any entity, I get INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate followed by nice friendly suggestions about filing a WebCase. Anyone else met this? I fixed it by adding a dummy value to the enumeration, but that's a bit rubbish, isn't it? I'll file the case, but thought y'all might be interested. -- Jonathan BromleyArticle: 152048
On 27/06/11 23:36, Jonathan Bromley wrote: > It was all going so well until I asked XST to compile a > VHDL entity with a generic of this type: > type video_modes_e is (vesa_1024x768_65Hz); > I guess I'll have more modes later, but just now I > need only the one. But as soon as I put a generic > of type video_modes_e on any entity, I get > INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate > followed by nice friendly suggestions about filing a WebCase. > > Anyone else met this? I fixed it by adding a dummy value to > the enumeration, but that's a bit rubbish, isn't it? > > I'll file the case, but thought y'all might be interested. Hi Jonathan, I've always told people it was safest to stick to generics that are integer (and subtypes thereof). Recently, I'd changed my tune, as various tools coped fine with boolean, enum, etc.. Now I will change my tune back again :-) Generally broken stuff in XST can be worked around by writing a wrapper round the top level - which is also a bit rubbish I suppose. regards Alan -- Alan FitchArticle: 152049
>It was all going so well until I asked XST to compile a >VHDL entity with a generic of this type: > type video_modes_e is (vesa_1024x768_65Hz); >I guess I'll have more modes later, but just now I >need only the one. But as soon as I put a generic >of type video_modes_e on any entity, I get > INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate >followed by nice friendly suggestions about filing a WebCase. > >Anyone else met this? I fixed it by adding a dummy value to >the enumeration, but that's a bit rubbish, isn't it? > >I'll file the case, but thought y'all might be interested. >-- >Jonathan Bromley I haven't met this, but it's the sort of degenerate case that I would not expect many parsers to handle well. Did you simulate it? --------------------------------------- Posted through http://www.FPGARelated.com
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