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
Hello, I want to run a post-synthesis simulation. I don't find where to choose the sources (Netlist post-synthesis) to launch the needed simulation from ISE 13.3. Does someone know how to do it ? I need some help. Simulator: ModelSim SE-64 10.0d Xilinx tools: 13.3 Molka PhD studentArticle: 153301
>Hello, > >I want to run a post-synthesis simulation. I don't find where to >choose the sources (Netlist post-synthesis) to launch the needed >simulation from ISE 13.3. > >Does someone know how to do it ? I need some help. > >Simulator: ModelSim SE-64 10.0d >Xilinx tools: 13.3 > >Molka >PhD student > Why do you want to do this? I have never had a reason to do this and my designs have all worked just fine. Just do a behavioural sim and ensure your design passes timing and you will be ok. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153302
Hi, I'm trying to create EDK repository with my own pcores. In one of this pcores I need to use special program to generate one of its VHDL source files. So during synthesis I need to execute something like: /path_to_repository/my_repository/pcores/my_core/hdl/vhdl/generator I tried to use TCL script for that purpose. I defined ELABORATE_PROC option in .mpd file which calls TCL script executing relative path like: exec pcores/my_core/hdl/vhdl/generator However, when I created XPS project in directory let say /path_to_project with "Project Peripheral Repository Search Path" set to /path_to_repository, add mentioned pcore into this project and try to generate bitstream, I get an error like "pcores/my_core/hdl/vhdl/generator no such file or directory". After a while I figured out, that TCL script inside my repository's pcore is executed in the project actual directory, so relative path pcores/my_core/hdl/vhdl/generator is extended to absolute path /path_to_project/pcores/my_core/hdl/vhdl/generator instead of expected /path_to_repository/pcores/my_core/hdl/vhdl/generator. Is there a way how I can change the working directory of the TCL script to the directory with my repository? Maybe some system variable with the content of "Project Peripheral Repository Search Path". Or maybe some other way, how to correctly do the described task (calling generator program) in my repository. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153303
>> I want to run a post-synthesis simulation. I don't find where to >> choose the sources (Netlist post-synthesis) to launch the needed >> simulation from ISE 13.3. >> >> Does someone know how to do it ? I need some help. >> >> Simulator: ModelSim SE-64 10.0d >> Xilinx tools: 13.3 >> >> Molka >> PhD student >> > > Why do you want to do this? I have never had a reason to do this and my > designs have all worked just fine. Just do a behavioural sim and ensure > your design passes timing and you will be ok. One scenario that comes to mind is to avoid annoying problems where the behavioural models are broken. See this thread about the Xilinx FIFO core: http://forums.xilinx.com/t5/Simulation-and-Verification/Spartan-6-FIFO-problem-in-13-1/td-p/154690 JoelArticle: 153304
For remote system capable to be USB host and to run Linux a good solution may be to use usbip: http://usbip.sf.net (via VPN if connection goes through a public network). Then both ChipScope and driver runs on developer's machine, and only USB requests/responses are forwarded via network. I have yet to evaluate the performance of such solution. -- Regards, WZabArticle: 153305
vsh <henry.val.scott@gmail.com> writes: > any comments on either VHDL or Verilog? Yes, *both* languages have comments! Traditionally, VHDL uses two dashes (--) to signify comments. The newer-fangled VHDL-2008 syntax also allows the use of C-style multi-line comments enclosed in /* */ pairs. As in so many other ways, Verilog uses c style syntax - both /* */ and // are valid. Does that help? Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 153306
On Jan 29, 12:04=A0am, vsh <henry.val.sc...@gmail.com> wrote: > any comments on either VHDL or =A0Verilog? Can't comment on VHDL other than to say it always strikes me as difficult to decipher and untidy looking. I'd be interested to know if there's anything useful that you can do in VHDL that you can't in Verilog. I'm a Verilog user and like the straight-forward syntax. Like anything you can make a mess if you don't try hard enough not to.Article: 153307
On Sun, 29 Jan 2012 18:25:55 -0600, kekely wrote:
> Hi,
>
> I'm trying to create EDK repository with my own pcores. In one of this
> pcores I need to use special program to generate one of its VHDL source
> files. So during synthesis I need to execute something like:
> /path_to_repository/my_repository/pcores/my_core/hdl/vhdl/generator
>
> I tried to use TCL script for that purpose. I defined ELABORATE_PROC
> option in .mpd file which calls TCL script executing relative path like:
> exec pcores/my_core/hdl/vhdl/generator
>
>
> However, when I created XPS project in directory let say
> /path_to_project with "Project Peripheral Repository Search Path" set to
> /path_to_repository, add mentioned pcore into this project and try to
> generate bitstream, I get an error like
> "pcores/my_core/hdl/vhdl/generator no such file or directory". After a
> while I figured out, that TCL script inside my repository's pcore is
> executed in the project actual directory, so relative path
> pcores/my_core/hdl/vhdl/generator is extended to absolute path
> /path_to_project/pcores/my_core/hdl/vhdl/generator instead of expected
> /path_to_repository/pcores/my_core/hdl/vhdl/generator.
>
>
> Is there a way how I can change the working directory of the TCL script
> to the directory with my repository? Maybe some system variable with the
> content of "Project Peripheral Repository Search Path". Or maybe some
> other way, how to correctly do the described task (calling generator
> program) in my repository.
I'm not sure whether this will help at all, but TCL scripts can know
where they are (as opposed to knowing where they're being called from),
by using
info script
This allows you to use paths relative to the script being run, regardless
of the current working directory.
Example:
# converts a path relative to the script being run, into an absolute one.
proc file_rel2abs {path} {
if { [ string length [ info script ] ] > 0 } {
return [file normalize [file join [file dirname [info script]]
$path ] ]
} else {
error "confused"
}
}
N.B. info script doesn't work in Modelsim's TCL shell, if the script is
called using "do", however it does work if the script is run using
"source". This probably won't matter to you.
Regards,
Allan
Article: 153308>any comments on either VHDL or Verilog? > A competent designer could use either to implement a digital logic system. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153309
On Jan 30, 5:32=A0am, davew <david.wo...@gmail.com> wrote: > On Jan 29, 12:04=A0am, vsh <henry.val.sc...@gmail.com> wrote: > > > any comments on either VHDL or =A0Verilog? > > Can't comment on VHDL other than to say it always strikes me as > difficult to decipher and untidy looking. =A0I'd be interested to know > if there's anything useful that you can do in VHDL that you can't in > Verilog. > > I'm a Verilog user and like the straight-forward syntax. =A0Like > anything you can make a mess if you don't try hard enough not to. With the 2008 fixed point package, VHDL allows synthesizable fixed point arithmetic of arbitrary precision and binary point location. The arithmetic operators and types are defined to automatically handle mixed precision/point arithmetic for you. To the best of my knowledge, the Verilog language in its current form cannot support this capability at all. Similarly, VHDL also has a floating point package that handles arbitrary sizes of data and exponent. The fixed and floating point packages were demonstrated prior to 2008 with no changes to the language required (that's the power of VHDL types and overloading), and the only 2008 features that the current packages use are package generics, to allow user specification of operator behaviors for rounding, saturation, guard bits, etc. This highlights VHDL's inherent extensible capabilities that are completely lacking in Verilog. If all you use is std_logic, std_logic_vector, or arrays of same, there is negligible advantage to using VHDL over verilog. It is at higher levels of abstraction, where design productivity is maximized, that VHDL shines. Untidy is in the eye of the beholder. AndyArticle: 153310
Hi there, I'm using Xilinx 10.1(nt) K.31, and Aldec Active-HDL 8.1 (student). I used Aldec's design flow tools to implement a Coregen FIFO, and am using a recent, manufacturer-compiled version of XilinxCoreLib. The project (3 files: my vhdl, the fifo_generator vhdl and the fifo_gen .edn) compiles just fine, but when I go to simulate in Waveform Editor, the part responds "dumb" (all outputs and internal signals floating, no matter the input), and I get the following warnings: # ELBREAD: Warning: Library fifo_generator_v4_3_fifo_generator_v4_3_xst_1_lib not found. # ELBREAD: Warning: Design unit fifo_generator_v4_3_fifo_generator_v4_3_xst_1 instantiated in corefifo_test.fifo_generator_v4_3(fifo_generator_v4_3) not found in searched libraries: corefifo_test, fifo_generator_v4_3_fifo_generator_v4_3_xst_1_lib. # ELBREAD: Warning: Component /fifo1/BU2 : fifo_generator_v4_3_fifo_generator_v4_3_xst_1 not bound. # ELBREAD: Warning: Design unit GND instantiated in corefifo_test.fifo_generator_v4_3(fifo_generator_v4_3) not found in searched libraries: corefifo_test, spartan3a. # ELBREAD: Warning: Component /fifo1/GND : GND not bound. I've checked what exists in my XilinxCoreLib, and I've got all the following: fifo_generator_v4_3 fifo_generator_v4_3_bhv_as fifo_generator_v4_3_bhv_preload0 fifo_generator_v4_3_bhv_ss fifo_generator_v4_3_xst So I know that the xst source exists, and is compiled into the library. Any help would be greatly appreciated!Article: 153311
On Jan 29, 9:36=A0am, "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > >Hello, > > >I want to run a post-synthesis simulation. I don't find where to > >choose the sources (Netlist post-synthesis) to launch the needed > >simulation from ISE 13.3. > > >Does someone know how to do it ? I need some help. > > >Simulator: ModelSim SE-64 10.0d > >Xilinx tools: 13.3 > > >Molka > >PhD student > > Why do you want to do this? I have never had a reason to do this and my > designs have all worked just fine. Just do a behavioural sim and ensure > your design passes timing and you will be ok. > > Jon > > --------------------------------------- > Posted throughhttp://www.FPGARelated.com I would qualify that you should run full simulations on RTL, run STA with complete and accurate timing constraints on the design, and then run a subset of your simulation post-P&R. If you have any non-timing issues PPR, then you might try a post-synthesis simulation to isolate the problem to synthesis or P&R. One of the issues not caught by behavioral simulation plus STA is the accuracy of false- and multi- cycle-path constraints. If you use these in STA, they need to be verified by PPR simulation. AndyArticle: 153312
Andy <jonesandy@comcast.net> wrote: (snip) >> > any comments on either VHDL or Verilog? (snip) > With the 2008 fixed point package, VHDL allows synthesizable fixed > point arithmetic of arbitrary precision and binary point location. The > arithmetic operators and types are defined to automatically handle > mixed precision/point arithmetic for you. To the best of my knowledge, > the Verilog language in its current form cannot support this > capability at all. An interesting idea, but note that, as far as I know, no computer hardware has support for this, so it seems strange that an HDL would need it. Yes you can do fixed point with different positions of the radix point, PL/I and a small number of other languages do, but on hardware that doesn't keep track of the radix point. For multiply, you do need to keep all the product digits, so that you can select the right ones based on the position of the product radix point. > Similarly, VHDL also has a floating point package that handles > arbitrary sizes of data and exponent. And that is synthesizable by anyone? > The fixed and floating point packages were demonstrated prior to 2008 > with no changes to the language required (that's the power of VHDL > types and overloading), and the only 2008 features that the current > packages use are package generics, to allow user specification of > operator behaviors for rounding, saturation, guard bits, etc. This > highlights VHDL's inherent extensible capabilities that are completely > lacking in Verilog. I suppose higher level of abstraction is nice, but does it really help design real systems? > If all you use is std_logic, std_logic_vector, or arrays of same, > there is negligible advantage to using VHDL over verilog. And maybe a slight disadvantage. It is a lot wordier to say the same thing, more places to get it wrong. > It is at higher levels of abstraction, where design > productivity is maximized, that VHDL shines. Probaby depends on what kind of systems you design. Is it easier to design something like a pentium with a language that has support for floating point? For real floating point systems, it is usual to actually design the logic in the HDL. > Untidy is in the eye of the beholder. -- glenArticle: 153313
On Jan 30, 1:42=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Andy <jonesa...@comcast.net> wrote: > > (snip) > > >> > any comments on either VHDL or =A0Verilog? > > (snip) > > > With the 2008 fixed point package, VHDL allows synthesizable fixed > > point arithmetic of arbitrary precision and binary point location. The > > arithmetic operators and types are defined to automatically handle > > mixed precision/point arithmetic for you. To the best of my knowledge, > > the Verilog language in its current form cannot support this > > capability at all. > > An interesting idea, but note that, as far as I know, no computer > hardware has support for this, so it seems strange that an HDL > would need it. Whaaaatttt??? What does your computer capabilities have to do with your ASIC/FPGA designs? Mixed precision/radix point arithmetic can be very useful in an HDL design. If you are just passing data and controlling timing then maybe not. But signal processing often has to deal with the results of varying precision in operations. > Yes you can do fixed point with different positions of the radix > point, PL/I and a small number of other languages do, but on hardware > that doesn't keep track of the radix point. You seem to be thinking only of CPU designs. HDL is used for a lot more than CPU designs. > For multiply, you do need to keep all the product digits, so that > you can select the right ones based on the position of the product > radix point. Actually you need to keep the bits that are important to your application. That will vary. > > Similarly, VHDL also has a floating point package that handles > > arbitrary sizes of data and exponent. > > And that is synthesizable by anyone? I haven't looked at the floating point package, but if it is described in terms of basic operators in VHDL it should be synthesizable in every tool. That is the point of overloading. You can define a multiply operator for real data in terms of the basic building blocks and this is now a part of the language. VHDL is extensible that way. > > The fixed and floating point packages were demonstrated prior to 2008 > > with no changes to the language required (that's the power of VHDL > > types and overloading), and the only 2008 features that the current > > packages use are package generics, to allow user specification of > > operator behaviors for rounding, saturation, guard bits, etc. This > > highlights VHDL's inherent extensible capabilities that are completely > > lacking in Verilog. > > I suppose higher level of abstraction is nice, but does it really > help design real systems? Not if you refuse to consider it. > > If all you use is std_logic, std_logic_vector, or arrays of same, > > there is negligible advantage to using VHDL over verilog. > > And maybe a slight disadvantage. It is a lot wordier to say > the same thing, more places to get it wrong. Yes, VHDL is definitely wordier. But then I never use std_logic_vector or std_logic. I use signed and unsigned which provide so much more functionality... also provided by the extensibility of VHDL I believe. > > It is at higher levels of abstraction, where design > > productivity is maximized, that VHDL shines. > > Probaby depends on what kind of systems you design. > > Is it easier to design something like a pentium with a language that > has support for floating point? For real floating point systems, it > is usual to actually design the logic in the HDL. You seem to be very CPU focused. For every Pentium type design done in HDL there are what, thousands of other designs? > > Untidy is in the eye of the beholder. > > -- glen RickArticle: 153314
rickman <gnuarm@gmail.com> wrote: (snip, someone wrote) >> > With the 2008 fixed point package, VHDL allows synthesizable fixed >> > point arithmetic of arbitrary precision and binary point location. (snip, I wrote) >> An interesting idea, but note that, as far as I know, no computer >> hardware has support for this, so it seems strange that an HDL >> would need it. > Whaaaatttt??? What does your computer capabilities have to do with > your ASIC/FPGA designs? Mixed precision/radix point arithmetic can be > very useful in an HDL design. If you are just passing data and > controlling timing then maybe not. But signal processing often has to > deal with the results of varying precision in operations. If it is useful in ASIC/FPGA designs, wouldn't it also be even more useful in software running on commonly (or not so commonly) available processors? Yet none have bothered to implement it. It could be done in software, but none of the popular languages have any support for fixed point non-integer arithmetic. It was one of the fun things I did in PL/I so many years ago, though. >> Yes you can do fixed point with different positions of the radix >> point, PL/I and a small number of other languages do, but on hardware >> that doesn't keep track of the radix point. > You seem to be thinking only of CPU designs. HDL is used for a lot > more than CPU designs. Well, more than CPU designs, I work on systolic arrays, but even there so, it doesn't seem likely to help much. Will it generate pipelined arithmetic units? Of all the things that I have to think about in logic design, the position of the binary point is one of the smallest. >> For multiply, you do need to keep all the product digits, so that >> you can select the right ones based on the position of the product >> radix point. > Actually you need to keep the bits that are important to your > application. That will vary. And I don't expect the processor to help me figure out which ones those are. >> > Similarly, VHDL also has a floating point package that handles >> > arbitrary sizes of data and exponent. >> >> And that is synthesizable by anyone? > I haven't looked at the floating point package, but if it is described > in terms of basic operators in VHDL it should be synthesizable in > every tool. That is the point of overloading. You can define a > multiply operator for real data in terms of the basic building blocks > and this is now a part of the language. VHDL is extensible that way. Again, does it synthesize pipelined arithmetic units? If not, then they aren't much use to anything I would work on. If I do it in an FPGA that is because normal processors aren't fast enough. But the big problem with floating point is that it takes too much logic. The barrel shifter for pre/post normalization for an adder is huge. (The actual addition, not so huge.) (snip) >> I suppose higher level of abstraction is nice, but does it really >> help design real systems? > Not if you refuse to consider it. (snip) > You seem to be very CPU focused. For every Pentium type design done > in HDL there are what, thousands of other designs? Well, it was supposed to be an example.... -- glenArticle: 153315
davew <david.wooff@gmail.com> wrote: >On Jan 29, 12:04=A0am, vsh <henry.val.sc...@gmail.com> wrote: >> any comments on either VHDL or =A0Verilog? > >Can't comment on VHDL other than to say it always strikes me as >difficult to decipher and untidy looking. I'd be interested to know >if there's anything useful that you can do in VHDL that you can't in >Verilog. > >I'm a Verilog user and like the straight-forward syntax. Like >anything you can make a mess if you don't try hard enough not to. IMHO Verilog is about describing hardware and VHDL is about describing what it should do. VHDL has been good to me but it did take reading some books and experimenting for me to unleash its real power. If you overcome the stage where you describe hardware (thinking in 74' logic chips) and start describing what a piece of logic should do you can do a lot with just a few lines of VHDL by using functions, records, etc. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 153316
On 30 jan, 12:32, roleohibachi <roleohiba...@gmail.com> wrote: > Hi there, > I'm using Xilinx 10.1(nt) K.31, and Aldec Active-HDL 8.1 (student). I > used Aldec's design flow tools to implement a Coregen FIFO, and am > using a recent, manufacturer-compiled version of XilinxCoreLib. > The project (3 files: my vhdl, the fifo_generator vhdl and the > fifo_gen .edn) compiles just fine, but when I go to simulate in > Waveform Editor, the part responds "dumb" (all outputs and internal > signals floating, no matter the input), and I get the following > warnings: > > # ELBREAD: Warning: Library > fifo_generator_v4_3_fifo_generator_v4_3_xst_1_lib not found. > # ELBREAD: Warning: Design unit > fifo_generator_v4_3_fifo_generator_v4_3_xst_1 instantiated in > corefifo_test.fifo_generator_v4_3(fifo_generator_v4_3) not found in > searched libraries: corefifo_test, > fifo_generator_v4_3_fifo_generator_v4_3_xst_1_lib. > # ELBREAD: Warning: Component /fifo1/BU2 : > fifo_generator_v4_3_fifo_generator_v4_3_xst_1 not bound. > # ELBREAD: Warning: Design unit GND instantiated in > corefifo_test.fifo_generator_v4_3(fifo_generator_v4_3) not found in > searched libraries: corefifo_test, spartan3a. > # ELBREAD: Warning: Component /fifo1/GND : GND not bound. > > I've checked what exists in my XilinxCoreLib, and I've got all the > following: > =A0 fifo_generator_v4_3 > =A0 fifo_generator_v4_3_bhv_as > =A0 fifo_generator_v4_3_bhv_preload0 > =A0 fifo_generator_v4_3_bhv_ss > =A0 fifo_generator_v4_3_xst > > So I know that the xst source exists, and is compiled into the > library. > > Any help would be greatly appreciated! 1 - First, you must download the 10.1 libraries for Aldec 8.1, not the newest verion of the Xilinx libraries since they probably are for version ISE 13.1. Make sure you do not download libraries for Aldec 8.3 either. 2 - If you go in the library manager in Active-HDL, check the different Xilinx libraries and you should be able to see what version of the fifo generator you have. For example, check unisim or Xilinxcorelib, names similar to that. 3 - There is a global library file somewhere for Aldec, don't remember where exactly, but if your library is missing in the library manager, you need to add this library to the global library file.Article: 153317
On 28/01/2012 20:58, david wrote: > > > Hello somebody Know how to link matlab with any device with tcp/ip > comunication > > Iam david. Look in the Mathworks File Exchange for TCP/UDP/IP Toolbox 2.0.6 It is free and the UDP bit certainly works OK. Michael KellettArticle: 153318
>>> I want to run a post-synthesis simulation. I don't find where to >>> choose the sources (Netlist post-synthesis) to launch the needed >>> simulation from ISE 13.3. >>> >>> Does someone know how to do it ? I need some help. >>> >>> Simulator: ModelSim SE-64 10.0d >>> Xilinx tools: 13.3 >>> >>> Molka >>> PhD student >>> >> >> Why do you want to do this? I have never had a reason to do this and my >> designs have all worked just fine. Just do a behavioural sim and ensure >> your design passes timing and you will be ok. > >One scenario that comes to mind is to avoid annoying problems where the >behavioural models are broken. See this thread about the Xilinx FIFO core: > >http://forums.xilinx.com/t5/Simulation-and-Verification/Spartan-6-FIFO-problem-in-13-1/td-p/154690 > >Joel The correct workaround for this problem is to generate Structural FIFO models, and use them in your pre-synthesis simulations. AFAIK, all the Behavioural FIFO models are broken. I can think of other reasons to do post-PAR simulations, for instance if you have a tricksy start-up sequence involving multiple clocks. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153319
Glen, The point of optimizing HW arithmetic to the task at hand is that avoiding excess precision saves resources (= $). In SW, running on a majority of platforms that support double precision floating point (already paid for whether it is used or not) there is no incentive to optimize, so few computer programming languages support it. Many older programming languages, conceived before HW floating point support was ubiquitous, supported fixed point arithmetic because the SW could be optimized to provide only the precision required, thus consuming only the CPU cycles required. CPUs have to be optimized for the universe of applications that may be run on them, so the flexibility of floating point is worth the cost, especially because only one or two floating point ALUs are typically required by a CPU core. Most ASIC/FPGA designs are much more task specific, and do not need the flexibility of floating point, especially when considering how many arithmetic units (multiply/add) may be employed by a typical design, and thus how many times one would have to pay for the resources consumed by that unneeded flexibility. Sure, you can design fixed point arithmetic HW in verilog, but you have to keep track of the binary point yourself, with no help from the compiler. These VHDL packages allow you to define the width and binary point at critical stages, and the compiler takes care of the rest. Most synthesis tools support retiming, which can be used to pipeline arithmetic operators over a limited number of clock cycles by simply inserting empty clock cycles in RTL before or after the operator, and letting the retiming spread out the operator logic into those clock cycles. With most modern FPGA families, multiplies and multiply/adds are implemented using available DSP blocks anyway, so intra-operator pipelining is not often needed uness you have a really wide data path. And of course, just like verilog, you are in charge of pipelining multiple operations by the way you describe the behavior (number of clock cycles it takes to get from input to output). Note that I use the term clock cycles as opposed to registers. It's an abstraction... And yes, both the floating and fixed point packages are completely synthesizable. AndyArticle: 153320
Thanks for your help. Turns out, all the libraries were spot-on, and it did= n't make a difference whether it was attached globally or locally.=20 Called Aldec, took an hour. Made a newbie mistake. Here's the details, for = anyone with the same problem later: I was including the EDIF (.edn) file in the compilation. The EDIF is for sk= ipping synthesis and has nothing to do with compiling. It was automatically= generated by the CoreGen Wizard, and I had just assumed it was a dependenc= y for the FIFO. The compiler was allowing it, but in elaboration, it barfed= . All I had to do was exclude the .edn file from compilation, and everythin= g worked. Thanks again.Article: 153321
Andy <jonesandy@comcast.net> writes: > there is negligible advantage to using VHDL over verilog. It is at > higher levels of abstraction, where design productivity is maximized, > that VHDL shines. It depends of the Verilog version in question and the type of design. SystemVerilog has a much higher level of abstraction when it comes to verification and testbench code. Especially when using libraries like UVM etc. //Petter -- .sig removed by request.Article: 153322
>On Sun, 29 Jan 2012 18:25:55 -0600, kekely wrote:
>
>> Hi,
>>
>> I'm trying to create EDK repository with my own pcores. In one of this
>> pcores I need to use special program to generate one of its VHDL source
>> files. So during synthesis I need to execute something like:
>> /path_to_repository/my_repository/pcores/my_core/hdl/vhdl/generator
>>
>> I tried to use TCL script for that purpose. I defined ELABORATE_PROC
>> option in .mpd file which calls TCL script executing relative path
like:
>> exec pcores/my_core/hdl/vhdl/generator
>>
>>
>> However, when I created XPS project in directory let say
>> /path_to_project with "Project Peripheral Repository Search Path" set
to
>> /path_to_repository, add mentioned pcore into this project and try to
>> generate bitstream, I get an error like
>> "pcores/my_core/hdl/vhdl/generator no such file or directory". After a
>> while I figured out, that TCL script inside my repository's pcore is
>> executed in the project actual directory, so relative path
>> pcores/my_core/hdl/vhdl/generator is extended to absolute path
>> /path_to_project/pcores/my_core/hdl/vhdl/generator instead of expected
>> /path_to_repository/pcores/my_core/hdl/vhdl/generator.
>>
>>
>> Is there a way how I can change the working directory of the TCL script
>> to the directory with my repository? Maybe some system variable with
the
>> content of "Project Peripheral Repository Search Path". Or maybe some
>> other way, how to correctly do the described task (calling generator
>> program) in my repository.
>
>
>I'm not sure whether this will help at all, but TCL scripts can know
>where they are (as opposed to knowing where they're being called from),
>by using
>
>info script
>
>This allows you to use paths relative to the script being run, regardless
>of the current working directory.
>
>Example:
>
># converts a path relative to the script being run, into an absolute
one.
>proc file_rel2abs {path} {
> if { [ string length [ info script ] ] > 0 } {
> return [file normalize [file join [file dirname [info script]]
>$path ] ]
> } else {
> error "confused"
> }
>}
>
>
>N.B. info script doesn't work in Modelsim's TCL shell, if the script is
>called using "do", however it does work if the script is run using
>"source". This probably won't matter to you.
>
>Regards,
>Allan
>
Thank you for such a quick reply.
Unfortunately, proposed solution didn't work in my situation. I know about
"info script", but when I tried it in my script, it returned only empty
string. Therefore, when I tried your proposed function "file_rel2abs", it
ended with error "confused".
Lukas
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 153323On Jan 30, 6:16=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > rickman <gnu...@gmail.com> wrote: > > (snip, someone wrote) > > >> > With the 2008 fixed point package, VHDL allows synthesizable fixed > >> > point arithmetic of arbitrary precision and binary point location. > > (snip, I wrote) > > >> An interesting idea, but note that, as far as I know, no computer > >> hardware has support for this, so it seems strange that an HDL > >> would need it. > > Whaaaatttt??? =A0What does your computer capabilities have to do with > > your ASIC/FPGA designs? =A0Mixed precision/radix point arithmetic can b= e > > very useful in an HDL design. =A0If you are just passing data and > > controlling timing then maybe not. =A0But signal processing often has t= o > > deal with the results of varying precision in operations. > > If it is useful in ASIC/FPGA designs, wouldn't it also be even more > useful in software running on commonly (or not so commonly) available > processors? Yet none have bothered to implement it. > > It could be done in software, but none of the popular languages > have any support for fixed point non-integer arithmetic. > > It was one of the fun things I did in PL/I so many years ago, though. I don't really follow your reasoning here. The idea of the fixed point package is to allow a user to work with fixed point values in VHDL without having to manually deal with all the details. You seem to be saying that fixed point arithmetic is of no value because it is not implemented in software. I don't see how software has anything to do with it. Software is implemented on programmable hardware and for the most part is designed for the most common platforms and does not do a good job of utilizing unusual hardware effectively. I don't see how fixed point arithmetic would be of any value on conventional integer oriented hardware. > >> Yes you can do fixed point with different positions of the radix > >> point, PL/I and a small number of other languages do, but on hardware > >> that doesn't keep track of the radix point. > > You seem to be thinking only of CPU designs. =A0HDL is used for a lot > > more than CPU designs. > > Well, more than CPU designs, I work on systolic arrays, but even > there so, it doesn't seem likely to help much. Will it generate > pipelined arithmetic units? Of all the things that I have to think > about in logic design, the position of the binary point is one of > the smallest. Asking about pipelining with fixed point numbers is like asking if boxes help your car. Sure, if you want to carry oranges in a car you can use boxes, but you don't have to. If your systolic arrays use fixed point arithmetic then the fixed point package will help your systolic arrays. If you don't care about the precision of your calculations then don't bother using the fixed point package. > >> For multiply, you do need to keep all the product digits, so that > >> you can select the right ones based on the position of the product > >> radix point. > > Actually you need to keep the bits that are important to your > > application. =A0That will vary. > > And I don't expect the processor to help me figure out which > ones those are. What processor? You have lost me here. A multiply provides a result with as many bits as the sum of the bits in the inputs. But this many bits are seldom needed. The fixed point package makes it a little easier to work with the variety of formats that typically are used in a case like this. No, the package does not figure out what you want to do. You have to know that, but it does help hide some of the details. > >> > Similarly, VHDL also has a floating point package that handles > >> > arbitrary sizes of data and exponent. > > >> And that is synthesizable by anyone? > > I haven't looked at the floating point package, but if it is described > > in terms of basic operators in VHDL it should be synthesizable in > > every tool. =A0That is the point of overloading. =A0You can define a > > multiply operator for real data in terms of the basic building blocks > > and this is now a part of the language. =A0VHDL is extensible that way. > > Again, does it synthesize pipelined arithmetic units? If not, then > they aren't much use to anything I would work on. If I do it in > an FPGA that is because normal processors aren't fast enough. > > But the big problem with floating point is that it takes too much logic. > The barrel shifter for pre/post normalization for an adder is huge. > (The actual addition, not so huge.) Nope, the fixed point package does not design pipelines, it isn't a pipeline package. Yup, the barrel shifter is as large as a multiplier. So what is your point? The purpose of the package is to allow you to design floating point arithmetic without designing all the details of the logic. It isn't going to reduce the size of the logic. > >> I suppose higher level of abstraction is nice, but does it really > >> help design real systems? > > Not if you refuse to consider it. > > (snip) > > > You seem to be very CPU focused. =A0For every Pentium type design done > > in HDL there are what, thousands of other designs? > > Well, it was supposed to be an example.... > > -- glen An example of what? The fact that you can't find the utility of the fixed point package does not mean it is not useful. I really don't see your points. RickArticle: 153324
On Tue, 31 Jan 2012 16:56:40 -0600, kekely wrote:
>>On Sun, 29 Jan 2012 18:25:55 -0600, kekely wrote:
>>
>>> Hi,
>>>
>>> I'm trying to create EDK repository with my own pcores. In one of
>>> this pcores I need to use special program to generate one of its VHDL
>>> source files. So during synthesis I need to execute something like:
>>> /path_to_repository/my_repository/pcores/my_core/hdl/vhdl/generator
>>>
>>> I tried to use TCL script for that purpose. I defined ELABORATE_PROC
>>> option in .mpd file which calls TCL script executing relative path
> like:
>>> exec pcores/my_core/hdl/vhdl/generator
>>>
>>>
>>> However, when I created XPS project in directory let say
>>> /path_to_project with "Project Peripheral Repository Search Path" set
> to
>>> /path_to_repository, add mentioned pcore into this project and try to
>>> generate bitstream, I get an error like
>>> "pcores/my_core/hdl/vhdl/generator no such file or directory". After a
>>> while I figured out, that TCL script inside my repository's pcore is
>>> executed in the project actual directory, so relative path
>>> pcores/my_core/hdl/vhdl/generator is extended to absolute path
>>> /path_to_project/pcores/my_core/hdl/vhdl/generator instead of expected
>>> /path_to_repository/pcores/my_core/hdl/vhdl/generator.
>>>
>>>
>>> Is there a way how I can change the working directory of the TCL
>>> script to the directory with my repository? Maybe some system variable
>>> with
> the
>>> content of "Project Peripheral Repository Search Path". Or maybe some
>>> other way, how to correctly do the described task (calling generator
>>> program) in my repository.
>>
>>
>>I'm not sure whether this will help at all, but TCL scripts can know
>>where they are (as opposed to knowing where they're being called from),
>>by using
>>
>>info script
>>
>>This allows you to use paths relative to the script being run,
>>regardless
>
>>of the current working directory.
>>
>>Example:
>>
>># converts a path relative to the script being run, into an absolute
> one.
>>proc file_rel2abs {path} {
>> if { [ string length [ info script ] ] > 0 } {
>> return [file normalize [file join [file dirname [info script]]
>>$path ] ]
>> } else {
>> error "confused"
>> }
>>}
>>
>>
>>N.B. info script doesn't work in Modelsim's TCL shell, if the script is
>>called using "do", however it does work if the script is run using
>>"source". This probably won't matter to you.
>>
>>Regards,
>>Allan
>>
>>
> Thank you for such a quick reply.
> Unfortunately, proposed solution didn't work in my situation. I know
> about "info script", but when I tried it in my script, it returned only
> empty string. Therefore, when I tried your proposed function
> "file_rel2abs", it ended with error "confused".
I'm no TCL expert, but I think you might be able to work around that by
making sure that you execute your script by "sourcing" it.
>From the manual page:
info script
If a Tcl script file is currently being evaluated (i.e. there is a
call to Tcl_EvalFile active or there is an active invocation of the
source command), then this command returns the name of the innermost file
being processed. Otherwise the command returns an empty string.
Regards,
Allan
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