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
That and also entity and file name should be the sameArticle: 87626
Sarath, In my humble opinion, a good ASIC RTL design is always going to become a good FPGA RTL design almost at no cost. I mostly did FPGA2ASIC, never done ASIC2FPGA, but I have no doubt about that. Moving on... You need to think of replacing memories, if they are instantiated as HDL macros, also any PLLs, I/O (if there are any), etc. but the datapath processing should remain the same. If you can give more details what are you facing, it would be easier to point to the tools, which usually are just a few good engineers. Vladislav "sarath" <sarath1111@gmail.com> wrote in message news:1122444179.117553.257740@f14g2000cwb.googlegroups.com... > Hi all, > Can any one list me out the various steps that need to be carried > out to convert ASIC RTL Code to FPGA RTL Code. In what way the ASIC RTL > Code differs from FPGA RTL Code. Can you also list me the various tools > that are available to perform them. > Thanks in Advance, > Sarath >Article: 87627
Hi everybody, I bought the isplever 5.0 to develope a project with a lattice cpld, serie ispmach. I used the schematic approach, and after some attempts, everything went well, and I got my cpld programmed and working. Now I need to put down a simple logic with a GAL16V8, using the schematic, but despite everybody says the ISPlever environment is simple and user-friendly, with some shame I must admit I could not get my project done. Apparently I don't find a way to assign the pin number of the real device at each point of my simple combinatory net. I previously only used the programmable logic design tool of my old Orcad4 under Dos, where I just wrote the pin assignments using simple text, in the schematic page, each row starting with a pipe. That approach doesn't work with the schematic editor in ISPlever, and I am not able to find a tutorial or some hint in the ISPlever Help. Any suggestion? Bye Strelnikov Come da oggetto: qualcuno ha pratica del pacchetto lattice isplever per progettare gal? Sono riuscito a utilizzarlo per le cpld senza troppi problemi, e adesso mi sto bloccando su una 16v8 probabilmente per qualche problema stupido... non ci sono tutorial per le gal e l'help è assolutamente laconico a riguardo...Article: 87628
Hello all, This issue has been here for a few times, so... I was wondering if there is a progress with an issue of portability error during timing-driven packing and placement and when this fix is going to be released. Usually, I was able to manage without it, but now I have a design which is barely meeting the timing without it (it was previously doing good with it) Thank you VladislavArticle: 87629
> There is a pin error in the footprint of the EP2C8F256. > The F5, LVDS13p is alone, there is no LVDS13n, > which has to be for a true LVDS channel. > > Can anyone confirm this ? It basically means there > is no LVDS13. Hi Rene, My answer was somewhat cryptive, the die pad LVDS13n is simply not available on this package. So it is available on the die, and in the Q208 package, but not in the F256 package. There it is replaced by some dedicated pins for config.Article: 87630
Peter K. wrote: > Rune Allnor wrote: > > > Well, I did see -- from a safe distance, thankfully -- a software > > project in progress, that did "produce results" extremely quickly. > > [SNIP] > > > All my efforts to get the department to make decisions on data > > formats, analysis tools, establish procedures for QC, data validation, > > storage formats, reporting standards etc (I thought that getting/making > > a software tool for these kinds of jobs might force people to make > > decisions of this nature) were met with "It generates too much > > bueracracy, people do what they want anyway, and it takes no time to > > make a system for the scarcely few instances it might be useful." > > If it could be truly demonstrated that, for this particular company, > that approach worked... why not? It's about proepr use of manpower. Manually, the post-experiment data organization work takes 3-6 months, prior to any analysis. Most of it is drudgery. Automize that to take, say, 1 - 2 weeks, and the crew is free to do interesting or even useful stuff. And you can cut project time and cost with ridiculous amounts. > It certainly sounds like a pretty retrograde step they way you describe > it, but if the company could survive by doing things that way (even if > it goes against all the good ISO-9001:2000 / CMMI stuff), then it might > be a valid way to go. Some see the ISO 900x stuff as added bueracracy. It may well be, but it might also be a very powerful tool to streamline the production, if used wisely. In all the marine surveys I know of, either I have taken part myself, used the data or seen my colleagues be involved in, there have been ridiculous amounts of drudgery involved. I have seen -- not been involved in, personally, though -- surveys where it took 4-6 weeks from the guys came back to the lab to they could start working with the data. In the mean time they did QC, archiving, adding geometry, re-formatting,... you name it. People get unbelievably bored by doing this kind of work in the first place. Even more so, by doing it for so long time. When people are bored, they get sloppy. They make mistakes. There is no need to blame anyone for that, it's merely human nature. But we need the data, and we don't want all those inevitable mistakes, due to boredom, to invalidate the data. Experiments are expensive. Some times even useful. So the way to do this, is to formalize and automize as much of the process as possible. If you make a software system for format control, and make a sensible user interface, the crew can start the re-formatting job while in transit back from the survey site. After weeks at sea, they will most likely be in "zombie mode", but the are still capable of clikcking boxes in a GUI and filling in descriptions in a dialogue box, as required. A data validation system that take scarce pieces of information and stores it in reports, will save incredible amounts of time, not to mention if some reorganization of data files can be done as well. I wouldn't let anyone who have been to sea for any amount of time, near such a task for at least a month after the return, if it must be done manually. After a month, people will not be motivated to get back to work on the data, and we are back to the circle of boredom - demotivation - sloppyness - errors. So jumping on the ISO 900x frenzie provides managment with a nice diploma to hang on the wall, and the crew with an excuse to think their activities through. Not to mention that the ISO 900x certifcate is a compulsary requirement prior to getting certain types of projects. > I certainly have come across people who insist on taking an hour to do > something... and every time they do it it takes them an hour. Whereas > the I try to figure out how to automate it so that, the first time, it > might take me an hour and a half... but the second time takes my 20 > minutes, and subsequent times 5 minutes. The people who don't do the > hard hour every time don't appear to understand the tools at their > disposal, or can't systematize their thinking about the problem enough > to use them effectively. Well, it's a waste of my time if I have to wait for hours or weeks for them to provide me with the data I want and need. RuneArticle: 87631
"Antti Lukats" <antti@openchip.org> wrote in message news:dc5g2c$5dq$03$1@news.t-online.com... > "uxello" <uxello@free.fr> schrieb im Newsbeitrag > news:42e64094$0$20177$626a14ce@news.free.fr... > The first WebCase > we opened - the response from Xilixn was: - well there has been not much > interest in XCFxxP IEEE1532 BSDL files, so we have not made them. They are > scheduled for 2006. You have to wait. They seem to be available unless I am missing something: ftp://ftp.xilinx.com/pub/swhelp/bsdl/xcf.zip /MikhailArticle: 87632
Hello,
I have 2 32x512 brams. I'm using the parity bits to extend the available
data out a couple extra bits, so I can write a 66 bit word to the ram
(designed with Xilinx's core generator). Only problem is when I try to
specify what bits what go what bram in the bmm file, I get an error that I'm
exceeding the maximum data length. Is there some way to specify in the bmm
file that a couple of the bits are connected to the parity pins? My bmm
file is below:
ADDRESS_BLOCK capture_ram RAMB16 [0x00040400:0x000407FF]
BUS_BLOCK
INST_CAPRAM/B6 [35:0] ;
INST_CAPRAM/B10 [65:36] ;
END_BUS_BLOCK;
END_ADDRESS_BLOCK;
I get the following errors:
ERROR:Data2MEM:26 - Illegal bit lane width in ADDRESS_SPACE 'capture_ram'.
'INST_CAPRAM/B6 [35:0]' is by 36. Only 1, 2, 4, 8, 16, 32 is allowed.
ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE
'capture_ram'.
ADDRESS_SPACE was defined as 0x000000400 bytes, but the devices total
0x000000000 bytes.
Any ideas to get around this? Thanks,
-- Matt
+--
|Matthew Plante
| University of New Hampshire
| InterOperability Lab
| Research & Development
| SMTP: maplante@iol.unh.edu
| Phone: +1-603-862-0203
+-
Article: 87633"MM" <mbmsv@yahoo.com> schrieb im Newsbeitrag news:3kpl5hFvlb6mU1@individual.net... > "Antti Lukats" <antti@openchip.org> wrote in message > news:dc5g2c$5dq$03$1@news.t-online.com... > > "uxello" <uxello@free.fr> schrieb im Newsbeitrag > > news:42e64094$0$20177$626a14ce@news.free.fr... > > > The first WebCase > > we opened - the response from Xilixn was: - well there has been not much > > interest in XCFxxP IEEE1532 BSDL files, so we have not made them. They are > > scheduled for 2006. You have to wait. > > They seem to be available unless I am missing something: > ftp://ftp.xilinx.com/pub/swhelp/bsdl/xcf.zip > > > /Mikhail > > they are NOT, available are only IEEE1532 files for XCFxxS not for XCFxxP !! AnttiArticle: 87634
The parity bit support for BMM files was added very recently, it should be possible with the latest tools, but i dont know where the 'howto' is. checkout the picoblaze related stuff at xilinx web there they talk about 18 bit wide memory init antti "Matthew Plante" <maplante@iol.unh.edu> schrieb im Newsbeitrag news:dc877e$uv4$1@tabloid.unh.edu... > Hello, > > I have 2 32x512 brams. I'm using the parity bits to extend the available > data out a couple extra bits, so I can write a 66 bit word to the ram > (designed with Xilinx's core generator). Only problem is when I try to > specify what bits what go what bram in the bmm file, I get an error that I'm > exceeding the maximum data length. Is there some way to specify in the bmm > file that a couple of the bits are connected to the parity pins? My bmm > file is below: > > ADDRESS_BLOCK capture_ram RAMB16 [0x00040400:0x000407FF] > BUS_BLOCK > INST_CAPRAM/B6 [35:0] ; > INST_CAPRAM/B10 [65:36] ; > END_BUS_BLOCK; > END_ADDRESS_BLOCK; > > I get the following errors: > ERROR:Data2MEM:26 - Illegal bit lane width in ADDRESS_SPACE 'capture_ram'. > 'INST_CAPRAM/B6 [35:0]' is by 36. Only 1, 2, 4, 8, 16, 32 is allowed. > > > ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE > 'capture_ram'. > ADDRESS_SPACE was defined as 0x000000400 bytes, but the devices total > 0x000000000 bytes. > > Any ideas to get around this? Thanks, > > -- Matt > > +-- > |Matthew Plante > | University of New Hampshire > | InterOperability Lab > | Research & Development > | SMTP: maplante@iol.unh.edu > | Phone: +1-603-862-0203 > +- > >Article: 87635
> file what & where ?
> Ah, support request ? That is this personal login stuff ?
> A black hole, IMO.
>
Not necessarily: I have got two bugs fixed that way, one with the next
service-pack, for one I even got a patch within a few days. However, I have
to admit that I also had that feeling ("black hole") in the past. It depends
on who handles your request, and you need some patience. But I think it has
improved during the last year...
I think a SR is the right thing for your question as I suppost that noone
here can tell you more than you can guess yourself (just use another LVDS
pair that has p and n ;-)...
Thomas
Article: 87636Hi Antti, We're still using ISE 6.3.03i. I did just find that answer record you mentioned (#21460). So I guess the only solution is to upgrade to 7.1? Thanks, -- Matt "Antti Lukats" <antti@openchip.org> wrote in message news:dc87fp$kv0$03$1@news.t-online.com... > The parity bit support for BMM files was added very recently, it should be > possible with the latest tools, but i dont know where the 'howto' is. > checkout the picoblaze related stuff at xilinx web there they talk about > 18 > bit wide memory init > > antti > > > "Matthew Plante" <maplante@iol.unh.edu> schrieb im Newsbeitrag > news:dc877e$uv4$1@tabloid.unh.edu... >> Hello, >> >> I have 2 32x512 brams. I'm using the parity bits to extend the > available >> data out a couple extra bits, so I can write a 66 bit word to the ram >> (designed with Xilinx's core generator). Only problem is when I try to >> specify what bits what go what bram in the bmm file, I get an error that > I'm >> exceeding the maximum data length. Is there some way to specify in the > bmm >> file that a couple of the bits are connected to the parity pins? My bmm >> file is below: >> >> ADDRESS_BLOCK capture_ram RAMB16 [0x00040400:0x000407FF] >> BUS_BLOCK >> INST_CAPRAM/B6 [35:0] ; >> INST_CAPRAM/B10 [65:36] ; >> END_BUS_BLOCK; >> END_ADDRESS_BLOCK; >> >> I get the following errors: >> ERROR:Data2MEM:26 - Illegal bit lane width in ADDRESS_SPACE >> 'capture_ram'. >> 'INST_CAPRAM/B6 [35:0]' is by 36. Only 1, 2, 4, 8, 16, 32 is allowed. >> >> >> ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE >> 'capture_ram'. >> ADDRESS_SPACE was defined as 0x000000400 bytes, but the devices total >> 0x000000000 bytes. >> >> Any ideas to get around this? Thanks, >> >> -- Matt >> >> +-- >> |Matthew Plante >> | University of New Hampshire >> | InterOperability Lab >> | Research & Development >> | SMTP: maplante@iol.unh.edu >> | Phone: +1-603-862-0203 >> +- >> >> > >Article: 87637
I think it would be easiest to use Abel for a Gal device. You can find examples undert c:/ispTools/examples/spld/gal Alternatively you could also just use a 32 m/c device like a 4032v and do a schematic. Cost would likely be just a little more. TeoArticle: 87638
"Matthew Plante" <maplante@iol.unh.edu> schrieb im Newsbeitrag news:dc87ui$v3v$1@tabloid.unh.edu... > Hi Antti, > > We're still using ISE 6.3.03i. I did just find that answer record you > mentioned (#21460). So I guess the only solution is to upgrade to 7.1? > > Thanks, > > -- Matt there is no support for parity init before 7.1, so there is no other solution if you need this feature AnttiArticle: 87639
Hi Thomas, >> file what & where ? >> Ah, support request ? That is this personal login stuff ? Yep. >> A black hole, IMO. Not entirely. I have over 300 SRs on my account since 2000 that have been fixed by now. Most of them even within an agreeable timeframe. I will not make any further quantitative or qualitative remarks about Altera's support service - it sort of works for me. Anyway, I filed SR#10507655 with the following text regarding version 1.3 of the EP2C8 pin table: ==== Cut here ==== For the EP2C8, in the F256 package, on page 1, pin F5 is listed as LVDS13p. However, there is no corresponding LVDS13n for this package. If I assign signal zort2 to pin F5 using LVDS as an IO standard, Quartus II 5.0SP1 reports the following: Error: Can't place node positive with differential I/O zort2 in location (0,17,2) -- location does not support differential pin pair functionality Error: Can't place I/O pin zort2(n) in non-bonded location PAD_7 Error: Can't fit design in device Can you add a remark for the F256 package about this? ==== Cut here ==== Let's see what happens... Best regards, BenArticle: 87640
Hi, If you read the specs of the XCFxxP PROMs, you find: http://www.xilinx.com/bvdocs/publications/ds123.pdf (page 22 of 42) "At power up, the device requires the VCCINT power supply to monotonically rise to the nominal operating voltage within the specified VCCINT rise time." Is monotonicity in VCCINT so important for the XCFxxP PROMs? Why? (I understand monotonicity= positive slope) , or the only important thing is that the oe/reset line is released once VCCINT is stable? Cheers Pablo AlvarezArticle: 87641
Hi sarath, > Hi all, > Can any one list me out the various steps that need to be carried > out to convert ASIC RTL Code to FPGA RTL Code. In what way the ASIC RTL > Code differs from FPGA RTL Code. Can you also list me the various tools > that are available to perform them. Ususally you don't need a lot of tools to move from ASIC to FPGA. Most issues arise from design style. The big difference is that ASIC code is usually pretty cost-conscious when it comes to registers (DFFs), while these come for free in an FPGA.Usually, ASIC RTL therefore usually is deeply combinatorial in nature, which can be a performance bottleneck when implemented in an FPGA. FPGA designs tend to be far more pipelined. Also, 'special' components such as RAM blocks etc will need different names, as well as the fact that you don't need to instantiate your I/O pads. In this case, the tools needed are the data sheets and/or help files from the respective vendors. Best regards, BenArticle: 87642
still looking...Article: 87643
Dear
I am synthesizing and mapping following examples (counters) into Vertex
II pro with ISE6.3. Both of them are working okay in Modelsim.
And I wish to verify them after mapping using Chipscope Pro - Inserter
and Analyzer.
Version 1 is okay.
Version 2 is a version, which has "rst" input signal. Problem is that
version 2 not okay in ChipScope Pro, saying that " INFO - Device 2 Unit
0: Waiting for core to be armed ".
Both of them are error-free and warning-free during mapping process.
What is the problem in version 2? Is it really a problem? How can we
verify the version 2?
Thankyou again :) Regards
----- Version 1 ----------------------------------------
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
entity top is
port
(
clk : in std_logic := '0';
cnt : out std_logic_vector(3 downto 0)
);
end top;
architecture behave of top is
signal counter : std_logic_vector(31 downto 0):= (others => '0');
begin
process(clk)
begin
if ( clk'event and clk = '1' ) then
counter <= counter + 1;
end if;
end process;
cnt <= counter(31 downto 28);
end behave;
------- Version 2 -----------------------------------
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
entity top is
port
(
clk : in std_logic;
rst : in std_logic ; -- additional 'rst' input
cnt : out std_logic_vector(3 downto 0)
);
end top;
architecture behave of top is
signal counter : std_logic_vector(31 downto 0):= (others => '0');
signal rst_tmp: std_logic;
begin
rst_tmp <= rst;
process(clk)
begin
if rst_tmp='1' then
counter <= (others => '0');
elsif ( clk'event and clk = '1' ) then
counter <= counter + 1;
end if;
end process;
cnt <= counter(31 downto 28);
end behave;
-----------------------------------------------------
Article: 87644Rune Allnor wrote: > > If it could be truly demonstrated that, for this particular company, > > that approach worked... why not? > > It's about proepr use of manpower. Manually, the post-experiment > data organization work takes 3-6 months, prior to any analysis. > Most of it is drudgery. Automize that to take, say, 1 - 2 weeks, > and the crew is free to do interesting or even useful stuff. > And you can cut project time and cost with ridiculous amounts. Definitely! Show management the $ different between 3-6 months and 1-2 weeks, and you'll have your case sown up (they'll be begging you to do it!). > Some see the ISO 900x stuff as added bueracracy. It may well be, > but it might also be a very powerful tool to streamline the > production, if used wisely. I was involved in a small company that needed ISO9001-2000 accreditation to be considered as a supplier for a major company. The company was a start-up and we had complete freedom (within the constraints of ISO9001) to write our own procedures. What we did was to figure out what we were doing (and why we were doing it), look at some "best practices" to see if we should be doing anything else, and wrote that down as our quality manual. Because we had the luxury of defining it ourselves, and because we involved as many people as possible in the discussion about it, we had really good buy-in and understanding of why the process was necessary. Heck, we even passed ISO accredition first time with only the minimum allowable set of data (I think it was 3 months). My biggest reason for getting the system in place was for clarity of communicaiton: among team members, between teams, between team leaders and upper management, between our company and suppliers, between our company and customers. Ciao, Peter K.Article: 87645
On 27 Jul 2005 08:54:11 -0700, "pasacco" <pasacco@gmail.com> wrote:
>version 2 not okay in ChipScope Pro, saying that " INFO - Device 2 Unit
>0: Waiting for core to be armed ".
I don't understand this because I don't know about ChipScope Pro,
but I do understand why your VHDL is wrong.
>process(clk)
>begin
> if rst_tmp='1' then
> counter <= (others => '0');
> elsif ( clk'event and clk = '1' ) then
> counter <= counter + 1;
> end if;
>end process;
rst_tmp is required to reset the counter on both rising
and falling edges of the clock. This is clearly inappropriate
for any real devices.
>Both of them are error-free and warning-free during mapping process.
This is strange - the synthesis tool should reject it,
or at least issue a warning for the incorrect coding style.
>What is the problem in version 2? Is it really a problem?
If you want the reset to be synchronous, put it into the
clocked-logic part of the process so that it is tested
synchronously:
process(clk)
begin
if ( clk'event and clk = '1' ) then
if rst_tmp = '1' then
counter <= (others => '0');
else
counter <= counter + 1;
end if;
end if;
end process;
If you want the reset to be asynchronous, put it in the
sensitivity list and test it asynchronously:
process(clk, rst_tmp)
begin
if rst_tmp='1' then
counter <= (others => '0');
elsif ( clk'event and clk = '1' ) then
counter <= counter + 1;
end if;
end process;
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 87646"Jack" <JEmoderatz@yahoo.com> writes: > hi > > I need to measure "number of clock cycles" or "execution time", after > mapping the VHDL code into Vertex II pro. > > In Modelsim simulation, it took 350 cycles with 20 MHz clock frequency. > I hope the performance after the mapping will be same as the > performance in simulation. > Your hopes should be well founded. Assuming your design is fully-synchronous, and the timing analyser says it meets your 20MHz clock spec, the design will work as it does in simulation. > In ISE 6.3 (or EDK 6.3) , how can we measure the amount of clock > cycles? > You don't need to. <snip> Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 87647
Jonathan Bromley schrieb: > >>process(clk) >>begin >> if rst_tmp='1' then >> counter <= (others => '0'); >> elsif ( clk'event and clk = '1' ) then >> counter <= counter + 1; >> end if; >>end process; > > > rst_tmp is required to reset the counter on both rising > and falling edges of the clock. This is clearly inappropriate > for any real devices. It is an asynchronous reset. I think he should have rst_tmp in the sensitivity list. cheers GuntherArticle: 87648
Yes, I missed it. Reset signal "rst_tmp" should be within sensitivity
list. Below is the correct one.
BTW, my goal is to "verify" its functionality (of the "internal" 32 bit
counter) in a real FPGA chip.
In version 1, I am able to "see" the behavior of internal signals in
waveform (exactly same as simulation), using "Inserter" and "Analyzer"
in ChipScope Pro.
The difference between version 1 and 2 is the 'rst' input signal.
In version 2, however, no waveform can be seen in "Analyzer". That was
a problem :)
If someone has idea how to set up ChipScope Pro environment for this
case, let me know.
Thankyou so much. Regards
------- Version 2 ------------------------------=AD-----
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
entity top is
port
( clk : in std_logic;
rst : in std_logic ; -- additional 'rst' input
cnt : out std_logic_vector(3 downto 0) );
end top;
architecture behave of top is
signal counter : std_logic_vector(31 downto 0):=3D (others =3D> '0');
signal rst_tmp: std_logic :=3D '0'; -- initialization
begin
rst_tmp <=3D rst;
process(rst_tmp,clk)
begin
if rst_tmp=3D'1' then
counter <=3D (others =3D> '0');
elsif ( clk'event and clk =3D '1' ) then
counter <=3D counter + 1;
end if;
end process;
cnt <=3D counter(31 downto 28);
end behave;=20
------------------------------=AD-----------------------
Article: 87649Hello, I am pretty new to working with FPGAs and verilog in general but have a decent knowledge of programming, and Im trying to grasp the whole concept of working with the wishbone, as well as verilog architecture. I have the wishbone commax core and the ethernet ip core from opencores.org, and im wondering how to go about setting up a basic system to have some ethernet communication coming from my board which currently is a Virtex-4 board , with a PHY chip built onto it. I know the cores themselves already have a great setup, but im still unclear on how to just place it all together. Im going to keep trying to play around with it more and dig around more to see exactly how to do this, but im the meaintime some sort of basic example of how to go about setting it up would be greatly appreciated. Im not looking for code as much as im looking for just a genereal layout of the hierarchy that I could use in ISE (which im using for programming atm). Thank you for your time, Weizbox
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