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
ease modify the constraint. > > Does the little 2VP7 even have a SLICE_X100Y100? > Check the top corner coordinates in the floorplanner. > You may need a smaller range or a larger device. Yes, I just checked it and it works now thanks ;) INST "ARC_Ndp/Arc_Reg_File" AREA_GROUP = g1; AREA_GROUP "g1" RANGE = SLICE_X0Y0:SLICE_X15Y79,SLICE_X16Y0:SLICE_X27Y79; 79 is the maximum!Article: 136076
On Thu, 30 Oct 2008 10:25:33 +0000, Philipp <Patrick.Bateman23@gmx.at> wrote: >Thanks for all the feedback guys, I really appreciate it. Anyway, in the >meantime at least I managed it to work that the translate stage accepts >the ucf file which looks now as follows: > >INST "ARC_Ndp/Arc_Reg_File" AREA_GROUP = g1; >AREA_GROUP "g1" RANGE = SLICE_X10Y10,SLICE_X100Y100; >ERROR:MapHelpers:151 - Error while processing the area group range. >Unable to > create a LOC object using the constraint SLICE_X10Y10,SLICE_X100Y100 >attached > to area group g1. One or more ranges contain syntax error or illegal >site. > Please modify the constraint. Does the little 2VP7 even have a SLICE_X100Y100? Check the top corner coordinates in the floorplanner. You may need a smaller range or a larger device. - BrianArticle: 136077
Hi I use the RapidIO cores provided by Xilinx for my diploma thesis. I have recently upgraded to version 5.1 and I just cannot get the simulation to work. Before September's IP Update, I patched my own application into the simulation provided by Xilinx for SRIO 4_4, and everything worked just fine. With the new core, I can't even get the simple out of the box simulation to work. Anybody around with similar problems and maybe a solution? Any response is greatly appreciated! Thanks, H. DampfArticle: 136078
On 2008-10-30 13:33:51 +0100, Hans Dampf <bogus@nomail.bog> said: > Hi > > I use the RapidIO cores provided by Xilinx for my diploma thesis. I > have recently upgraded to version 5.1 and I just cannot get the > simulation to work. Before September's IP Update, I patched my own > application into the simulation provided by Xilinx for SRIO 4_4, and > everything worked just fine. > > With the new core, I can't even get the simple out of the box > simulation to work. > > Anybody around with similar problems and maybe a solution? > > Any response is greatly appreciated! > > Thanks, > > H. Dampf Perhaps I should clarify what the problem is... The problem with core 5.1 is that somehow, the transmitters don't get synchronized, so that the link won't become ready and the testbench times out..Article: 136079
Mark McDougall wrote: > I've little experience with ISE & its idiosyncrasies, but I've since been > told that this type of problem isn't uncommon. Apparently it's a little > too aggressive with its optimisation where duplicate logic is removed... Not sure who told you that, but I do that sort of thing all the time with variables in ISE 9.2, and have never had a bit of trouble. If you want to see a program that is extremely aggressive about finding and removing duplicate logic, try out Synplify sometime. But removing duplicate logic is a good thing, not bad. About the only difference in the way I code things is that I always put the clock enable within the clocked part of the process, and never in the sensitivity list (a clock enable should not be put there anyway).Article: 136080
> process (reset, clk, clk_ena) > =A0 variable hactive_v_r =A0: std_logic_vector(3 downto 0) :=3D (others = =3D> '0'); > begin > =A0 if reset =3D '1' then > =A0 =A0 hactive_v_r :=3D (others =3D> '0'); > =A0 elsif rising_edge(clk) and clk_ena =3D '1' then > =A0 =A0 ... > =A0 =A0 hactive_v_r :=3D hactive_v_r(hactive_v_r'left-1 downto 0) & hacti= ve_s; > =A0 end if; > end process; > > BTW 'h_active_s' is a signal declared in the containing entity, and is > definitely not optimised out. > > However, when building the project for Xilix under ISE 9.2.03i, I get the > following warnings during synthesis: > > WARNING:Xst:653 - Signal <hactive_v_r<3>> is used but never assigned. Tie= d > to value 0. > WARNING:Xst:1780 - Signal <hactive_v_r<2:0>> is never used or assigned. > Could it be that you have a signal declared which has the same name as the variable? Does anyone know if XST still warns that a signal is being removed, even if it's actually a variable? If there were a signal by the same name which is being optimized away, maybe XST gets confused and gets rid of both. DaveArticle: 136081
As promised another new product Polmaddie1 http://www.enterpoint.co.uk/cpld= _boards/polmaddie1.html. It's a very simple CPLD board based on Coolrunner-II. It's aimed at doing student or hobby learning with 4 sets of traffic lights to drive and you can even get your PC involved via the serial port providing FTDI FT232RQ chip that's on board. You can write custom software to drive this serial port or simply send charactors from a terminal emulator like Hyperterminal to drive sequences. We also made this project integration friendly with the main headers on a 0.1inch or 2.54mm grid so strip-board is a possible carrier of add-on electronics. The main headers will support up to 60 I/O between them and 3.3V and GND are there to support things hanging off on ribbon cables etc.. Pricing isn't 100% finalised but for lab quantities it will be around GBP=A320 - US$34, 26=80 on current exchange rates. As always let me know what you guys think of the product and what else you might like in this new product range. John Adair Enterpoint Ltd. - Providing VHDL and Verilog Training Platforms.Article: 136082
On Oct 30, 11:33=A0am, John Adair <g...@enterpoint.co.uk> wrote: > As promised another new product Polmaddie1http://www.enterpoint.co.uk/cpl= d_boards/polmaddie1.html. > It's a very simple CPLD board based on Coolrunner-II. It's aimed at > doing student or hobby learning with 4 sets of traffic lights to drive > and you can even get your PC involved via the serial port providing > FTDI FT232RQ chip that's on board. You can write custom software to > drive this serial port or simply send charactors from a terminal > emulator like Hyperterminal to drive sequences. > > We also made this project integration friendly with the main headers > on a 0.1inch or 2.54mm grid so strip-board is a possible carrier of > add-on electronics. The main headers will support up to 60 I/O between > them and 3.3V and GND are there to support things hanging off on > ribbon cables etc.. > > Pricing isn't 100% finalised but for lab quantities it will be around > GBP=A320 - US$34, 26=80 on current exchange rates. > > As always let me know what you guys think of the product and what else > you might like in this new product range. > > John Adair > Enterpoint Ltd. - Providing VHDL and Verilog Training Platforms. Very cute :) Just need to remote the traffic lights for the model RR junkies. 14.318 MHz sounds like a video frequency, not optimum for the UART baud rate, but high enough to get within 1% for the common rates. Was this frequency chosen based on price? Regards, GaborArticle: 136083
It is not clear if you are talking about an existing piece of hardware or a board to be designed. Generally speaking it shouldn't be a problem, but you need to have right connections on right pins using right type of traces on the board. /Mikhail "Moazzam" <moazzamhussain@gmail.com> wrote in message news:186ebd57-d1f7-4440-a869-78fe4f5aeb37@a70g2000hsh.googlegroups.com... > Hi, > > In one of my project, I am using two FPGAs on a custom board. The > first one is Xilinx Virtex-2 Pro XC2VP20 and the other one is > Spartan-3 (XC3S400). Virtex-2 Pro FPGA is driven by a clock of 32MHz > while Spartan-3 FPGA is driven by 19.6608MHz. > > A trivial approach to establish inter connectivity between the FPGAs > working in different clock domains is through a FIFO. (Just a > thought), I need to know if it is possible to provide 199.6608 MHz > clock to Virtex-2 Pro FPGA as an output from Spartan-3 FPGA. Both the > FPGA lie within 1.5 inches on multilayered board and whether the > current requirement of input clock can be met from the output of FPGA > pin ? > > > Regards > /MHArticle: 136084
The oscillator in the photo is in a socket so can be changed to whatever anyone wants to have. We already carry a wide range of these oscillators so supplying options isn't a problem. It's not fully decided if we will ship oscillators with the board as the FTDI chip can also output 6/12/24/48 MHz when reprogrammed from it's default state and we have wired that in. Once we have confirmed this functionality we will decide if to ship an oscillator or to leave as a clear socket. John Adair Enterpoint Ltd. On 30 Oct, 19:27, Gabor <ga...@alacron.com> wrote: > On Oct 30, 11:33=A0am, John Adair <g...@enterpoint.co.uk> wrote: > > > > > > > As promised another new product Polmaddie1http://www.enterpoint.co.uk/c= pld_boards/polmaddie1.html. > > It's a very simple CPLD board based on Coolrunner-II. It's aimed at > > doing student or hobby learning with 4 sets of traffic lights to drive > > and you can even get your PC involved via the serial port providing > > FTDI FT232RQ chip that's on board. You can write custom software to > > drive this serial port or simply send charactors from a terminal > > emulator like Hyperterminal to drive sequences. > > > We also made this project integration friendly with the main headers > > on a 0.1inch or 2.54mm grid so strip-board is a possible carrier of > > add-on electronics. The main headers will support up to 60 I/O between > > them and 3.3V and GND are there to support things hanging off on > > ribbon cables etc.. > > > Pricing isn't 100% finalised but for lab quantities it will be around > > GBP=A320 - US$34, 26=80 on current exchange rates. > > > As always let me know what you guys think of the product and what else > > you might like in this new product range. > > > John Adair > > Enterpoint Ltd. - Providing VHDL and Verilog Training Platforms. > > Very cute :) > > Just need to remote the traffic lights for the model RR junkies. > > 14.318 MHz sounds like a video frequency, not optimum for the > UART baud rate, but high enough to get within 1% for the common > rates. =A0Was this frequency chosen based on price? > > Regards, > Gabor- Hide quoted text - > > - Show quoted text -Article: 136085
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > My thought was stepper motors on each tuning peg. (Small and > geared down a lot.) Gibson makes a robotic self-tuning guitar that works this way I believe. G.Article: 136086
On Oct 29, 7:35=A0pm, Mark McDougall <ma...@vl.com.au> wrote:
> I've little experience with ISE & its idiosyncrasies, but I've since been
> told that this type of problem isn't uncommon. Apparently it's a little
> too aggressive with its optimisation where duplicate logic is removed...
>
> Regards,
>
> --
> Mark McDougall, Engineer
> Virtual Logic Pty Ltd, <http://www.vl.com.au>
> 21-25 King St, Rockdale, 2216
> Ph: +612-9599-3255 Fax: +612-9599-3266
I would also expect this to create flops, exactly as you seem to want.
Without the full details of the rest of your code, I took an educated
guess and made up some logic (foo). I tried out the following design
in ISE 9.1.02i and it created some nontrivial logic for hactive_v_r(3
downto 0), after synthesis (only, into the default xcv5vlx50 device)
and a glance at the RTL viewer.
Two other tangential thoughts crossed my mind as well:
(1) why do you have clk_ena in the sensitivity list? Here in the
Castle Anthrax there's only one punishment for random, desparate-
looking sensitivity lists :-)
(2) the question has often arisen here, as to why std_logic_arith and
std_logic_unsigned keep rearing their ugly heads in otherwise well-
intentioned code. One answer appeared when I (despite my better
instincts, and due to sheer laziness) used that damn-fool Xilinx
design entry wizard to create the top level shown below. "If Xilinx
does it, it must be right!", right?
Cheers, new Bruce.
- Kenn
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity fidget is
Port ( reset : in STD_LOGIC;
clk : in STD_LOGIC;
clk_ena : in STD_LOGIC;
hactive_input : in STD_LOGIC;
foo_output : out STD_LOGIC);
end fidget;
architecture Behavioral of fidget is
signal foo : std_logic;
signal hactive_s : std_logic;
begin
hactive_s <=3D hactive_input;
foo_output <=3D foo;
process (reset, clk, clk_ena)
variable hactive_v_r : std_logic_vector(3 downto 0) :=3D (others =3D>
'0');
begin
if reset =3D '1' then
hactive_v_r :=3D (others =3D> '0');
elsif rising_edge(clk) and clk_ena =3D '1' then
if hactive_v_r =3D "0000" then
foo <=3D not foo;
end if;
hactive_v_r :=3D hactive_v_r(hactive_v_r'left-1 downto 0) &
hactive_s;
end if;
end process;
end Behavioral;
Article: 136087Duane Clark wrote: > But removing > duplicate logic is a good thing, not bad. Agreed, but I've been told that the problem lies with duplicate logic and further optimisation that reveals that *one* of the "duplicated" logic blocks turns out to be ultimately unused - the optimiser then removes the "duplicated" logic and the *other* block, which *is* required, gets lost... Not speaking from and ISE experience myself, I'd guess that the order of optimisations gets a little screwed... or at least side effects aren't properly analysed. In any case, I'm assured that turning *OFF* all optimisations results in correctly-functioning code. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 136088
kennheinrich@sympatico.ca wrote: > Without the full details of the rest of your code, I took an educated > guess and made up some logic (foo). I tried out the following design > in ISE 9.1.02i and it created some nontrivial logic for hactive_v_r(3 > downto 0), after synthesis (only, into the default xcv5vlx50 device) > and a glance at the RTL viewer. I suspect that the problem requires more of my code to be included - the process itself is rather larger than my snippet in the posting... Try as I might, I can't see anything wrong with it myself, and the fact that (1) changing to signals works and (2) quartus works (with the original code) I still cling to my belief that it's an ISE bug... > (1) why do you have clk_ena in the sensitivity list? Here in the > Castle Anthrax there's only one punishment for random, desparate- > looking sensitivity lists :-) Noted! I probably picked up that habit long ago when first starting out and never gave it a second thought... you've just made a difference to someone - take the rest of the day off! :) > (2) the question has often arisen here, as to why std_logic_arith and > std_logic_unsigned keep rearing their ugly heads in otherwise well- > intentioned code. One answer appeared when I (despite my better > instincts, and due to sheer laziness) used that damn-fool Xilinx > design entry wizard to create the top level shown below. "If Xilinx > does it, it must be right!", right? Coincidently, I've just spent a few days going through my entire code base and removing all references to std_logic_arith. The most painful by far was my copious use of EXT(), which is now replaced with a much more cumbersome and less-flexible use of RESIZE(). :( It's something I've been putting off but every time I read a post on the subject I felt another pang of guilt! ;) Thanks for your comments! Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 136089
Dave wrote: > Could it be that you have a signal declared which has the same name as > the variable? No, sorry. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 136090
"Mark McDougall" <markm@vl.com.au> wrote in message news:490a52fa$1@dnews.tpgi.com.au... > kennheinrich@sympatico.ca wrote: > > Try as I might, I can't see anything wrong with it myself, and the fact > that (1) changing to signals works and (2) quartus works (with the > original code) I still cling to my belief that it's an ISE bug... > You've submitted this as a bug to the good folks at Xilinx, correct? It doesn't help you with the tool this time around, but eventually it gets fixed (if the submitters persist) or you move on to other tools, other suppliers. KJArticle: 136091
I haven't used those cores, but I know there were issues with some Rocket IO cores and Modelsim, older versions. Do you get any 'unbound' messages, or stuff like that? JTW "Moritz Schmid" <434128393> wrote in message news:2008103014113875249-434128393@news-europe.giganews.com... > On 2008-10-30 13:33:51 +0100, Hans Dampf <bogus@nomail.bog> said: > >> Hi >> >> I use the RapidIO cores provided by Xilinx for my diploma thesis. I have >> recently upgraded to version 5.1 and I just cannot get the simulation to >> work. Before September's IP Update, I patched my own application into the >> simulation provided by Xilinx for SRIO 4_4, and everything worked just >> fine. >> >> With the new core, I can't even get the simple out of the box simulation >> to work. >> >> Anybody around with similar problems and maybe a solution? >> >> Any response is greatly appreciated! >> >> Thanks, >> >> H. Dampf > > Perhaps I should clarify what the problem is... > The problem with core 5.1 is that somehow, the transmitters don't get > synchronized, so that the link won't become ready and the testbench times > out.. >Article: 136092
Hi, no there were no such problems. It's straight, flawless compilation and optimization. Anyway, I don't have to upgrade to the new cores. I just thought it would be nice, because Xilinx has fixed some problems of the old core, of which I am sure, I will run right into, when least expected... hans On 2008-10-31 04:37:29 +0100, "jtw" <wrightjt@hotmail.invalid> said: > I haven't used those cores, but I know there were issues with some Rocket IO > cores and Modelsim, older versions. Do you get any 'unbound' messages, or > stuff like that? > > JTW > "Moritz Schmid" <434128393> wrote in message > news:2008103014113875249-434128393@news-europe.giganews.com... >> On 2008-10-30 13:33:51 +0100, Hans Dampf <bogus@nomail.bog> said: >> >>> Hi >>> >>> I use the RapidIO cores provided by Xilinx for my diploma thesis. I have >>> recently upgraded to version 5.1 and I just cannot get the simulation to >>> work. Before September's IP Update, I patched my own application into the >>> simulation provided by Xilinx for SRIO 4_4, and everything worked just >>> fine. >>> >>> With the new core, I can't even get the simple out of the box simulation >>> to work. >>> >>> Anybody around with similar problems and maybe a solution? >>> >>> Any response is greatly appreciated! >>> >>> Thanks, >>> >>> H. Dampf >> >> Perhaps I should clarify what the problem is... >> The problem with core 5.1 is that somehow, the transmitters don't get >> synchronized, so that the link won't become ready and the testbench times >> out..Article: 136093
Hi, I am trying to build a simple PCI communication module. I am stuck with the error response due to an address parity error. I was wondering if someone had worked on something like this, they would probably know the answer. 1) If my module detects an address parity error but bit 8 in the command register used to turn on system error signaling is set to 0, does my system a) ignore the command b) Responds normally ignoring parity checking c) Takes possession of the request by asserting DEVSEL and then sends back a target abort. The PCI spec is not too clear about this particular case. Thanks for the help. AmishArticle: 136094
On Fri, 31 Oct 2008 11:26:32 +1100, Mark McDougall <markm@vl.com.au> wrote: >Duane Clark wrote: > >> But removing >> duplicate logic is a good thing, not bad. Usually... One case where removing duplicate logic IS harmful: when a registered signal is used internally, and also presented on output pins. XST will try to share the register, while you want to duplicate it to push registers into the output blocks for better I/O timing. You can turn "equivalent-register-removal" off globally with a flag, or for individual signals by attaching an attribute. Or you can "keep" signals which would otherwise be optimised away, with a "keep" atribute. Use sparingly; they will probably be harmlessly ignored by other tools, but don't really help portability. >Agreed, but I've been told that the problem lies with duplicate logic and >further optimisation that reveals that *one* of the "duplicated" logic >blocks turns out to be ultimately unused - the optimiser then removes the >"duplicated" logic and the *other* block, which *is* required, gets lost... If the other block really was required (as in, it was connected to an output or other logic (crucially; other logic which cannot itself be deleted!) it would have been kept. Though I have flamed XST , it is actually quite difficult to catch it out in real synthesis bugs and I don't believe you have here. (The one time I caught it creating incorrect logic, it got variables right, but not signals, when signals were modified within a procedure. In-lining the procedure calls in the main process gave correct results. Xilinx have acknowledged this bug and a change request has been filed. They really do want it to work right!) I suspect something obscure in the logic you didn't post is causing it to be simplified; therefore the other block appears redundant. >In any case, I'm assured that turning *OFF* all optimisations results in >correctly-functioning code. This may be expedient, but feels like glossing over the problem, which can re-appear later when something else changes. It may be worth simplifying the failing case to post here. Either you will see the problem in the process; or someone here may see it. Or, if you really have caught XST out, then you have a test case to attach to a Webcase reporting the bug. - BrianArticle: 136095
On Fri, 31 Oct 2008 11:36:05 +1100, Mark McDougall <markm@vl.com.au> wrote: >Try as I might, I can't see anything wrong with it myself, and the fact >that (1) changing to signals works and (2) quartus works (with the >original code) I still cling to my belief that it's an ISE bug... (Note: I haven't used Quartus; I may be doing it an injustice here) But here's my worry: What if XST is actually right; and Quartus is one step behind the pack in its optimisation technology (generating correct but sub-optimal results)? And the next revision of Quartus improves its optimisation algorithms... - BrianArticle: 136096
> Hi Eric, > > This is indeed a tricky area. I've implemented an S3 talking to DDR2 > components myself, and termination gave us loads of headaches. > First of all, what frequency are you trying to run at? I assume it's > somewhere around 133MHz, which is pretty slow by DDR2 standards and > you therefore you can ignore all of the dire warnings you see in > datasheets about correct termination being mandatory (assuming your > trace lengths aren't too long). > > DCI is a power-hog, but only when you use standards that have parallel > termination. In this case the DCI comprise a "Thevenin equivalent" > 200R accross the 1V8 supply for each IOB which can add up to a lot of > power dissipation. For series termination such as SSTL18_I_DCI the > series resistor adds little to the power consumption. > Therefore, for address and control signals I would recommend you use > SSTL18_I_DCI at the FPGA and termination to Vtt at the memory end. You > could probably also just use SSTL18_I at these speeds without any > problems. > > For the DQ/DQS signals I would use SSTL_18_II with an external 50R to > Vtt at the FPGA end, this needs to be fairly close to the FPGA pin, > but again at these frequencies it isn't that critical. At the memory > end use the ODT feature and save yourselves loads of termination > resistors. > > HTH, > Rob Rob, This is fantastic help, esp. since I just got quotes on IBIS simulators that exceed my entire budget for this project. :) I'm shooting for somewhere between 125 MHz and 150 MHz for my clock, and plan on having a very simple, bursty interface. I'm basically trying to clock this thing as slowly as I possibly can. I am using a single DDR2 IC (16-bit wide) per interface which will be directly connected to the FPGA as closely as possible. For the control signals, you recommend SSTL18_I_DCI on the FPGA side and a pull-up to VTT on the DDR2 side. You're then recommending using the SSTL_18_II IO standard for the DQ/ DQS signals on the FPGA side, with a 50 ohm pullup to VTT at the fpga side and just using ODT on the DDR2 side. If I understand correctly we can't use ODT for the address/control signals on the DDR2 side because DDR2 only supports ODT on data-related signals. For your interface, did you use the Xilinx Memory Interface generator, or do your own interface by hand? MIG tries to place what seem like significant restrictions on pin location, as well as being a bit too general-purpose for our applications, but I'm guessing if there are pin constraints there's a reason for it. Also, may I ask how far away your DDR2 ICs were from your FPGA, and if there was only a single IC per interface or multiple ICs? Thanks, ...EricArticle: 136097
On Oct 30, 9:47=A0pm, "KJ" <kkjenni...@sbcglobal.net> wrote: > "Mark McDougall" <ma...@vl.com.au> wrote in message > > news:490a52fa$1@dnews.tpgi.com.au... > > > kennheinr...@sympatico.ca wrote: > > > Try as I might, I can't see anything wrong with it myself, and the fact > > that (1) changing to signals works and (2) quartus works (with the > > original code) I still cling to my belief that it's an ISE bug... > > You've submitted this as a bug to the good folks at Xilinx, correct? =A0I= t > doesn't help you with the tool this time around, but eventually it gets > fixed (if the submitters persist) or you move on to other tools, other > suppliers. > > KJ I think there might be a mis-attribution here: it was Mark, not I, who clings to his belief. But more topically, Brian Drummond suggested in another post that there could be other stuff happening in other logic that causes the optimization to occur. If the code can be simplified to the point where it can be posted here and still show the bug, I will be happy to try it out on my version of ISE (and if motivated, even try out another synthesizer). If there's a real tool bug lurking here, let's kick it back the the vendor. - KennArticle: 136098
On Oct 31, 10:00=A0am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Fri, 31 Oct 2008 11:36:05 +1100, Mark McDougall <ma...@vl.com.au> > wrote: > > >Try as I might, I can't see anything wrong with it myself, and the fact > >that (1) changing to signals works and (2) quartus works (with the > >original code) I still cling to my belief that it's an ISE bug... > > (Note: I haven't used Quartus; I may be doing it an injustice here) > > But here's my worry: What if XST is actually right; and Quartus is one > step behind the pack in its optimisation technology (generating correct > but sub-optimal results)? > As always (and I'm assuming that Mark has already done this), you always run the simulator first to make sure that the design is functionally correct. Optimization that changes the observable function is incorrect optimization. Kevin JenningsArticle: 136099
HI Mikhail, Most of my slaves are custom built. I have been using a DCR bus and I like it, but it will become obsolete soon. Multiple PLBs connected to MPMC? Not a good idea If one Microblaze want to address all slaves. As far as I know MPMC bus bridging was removed from the core. Since I need to add more slaves I think I will add another Microblaze, another PLB and a PLB-PLB bridge. I have tons of free logic resources and a need some extra processing power. Thank you for the suggestions. Cheers, Ales On Oct 29, 9:02 pm, "MM" <mb...@yahoo.com> wrote: > Ales, > > I agree with Brian that it is not a good idea to try to modify the PLB bus > core. Even if you succeed now you will have problems down the road when you > decide that you need to upgrade the design to the next version . > > What are your slaves? Are any of them custom? Do they even have to be on PLB > bus? Consider DCR for slower peripherals that just a few registers. Also, > take a look at MPMC core, it allows to have multiple PLB busses and it might > be a better idea in some cases than a PLB-to-PLB bridge... > > /Mikhail > > <ales.gor...@gmail.com> wrote in message > > news:bf07a0b5-5429-44d5-bbd9-1366eac8fb21@t41g2000hsc.googlegroups.com... > > > Hi all, > > > I have encountered a problem where I least expected. > > I am using EDK 10.1.03 and I have build a system with 17 slaves on a > > PLBv4.6 bus. > > Well, the plb wrapper XPS reported an error: > > something like C_NUM_SLAVES = 17 is out of range [0:16] > > > What should I do? > > Use a bridge and add another PLB or copy plb_v46 core to local dir and > > expand the range to 17? > > > Cheers, > > > Ales
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