Signal Assignment bugs in Quartus-II ... AGAIN!

I've repeatedly reported this blatant and repeatedly acknowledged bug in Quartus-II's schematic editor, yet it appears it's still there in all its splendor in v7.1.

When I assign a bus named the software arbitrarily appends another signal group and binds them to arbitrary pins and misassigns my signals NAME[K] .. NAME[0] to other pin numbers, which, among other things, produces conflicts of assignment, not to mention that it completely fouls up my signal assignments.

Has anybody figured out how to get ONLY the CORRECT pin assignments to be used in the design?

Its not a bug, you clearly do not fully understand the rules for bus naming.

FRED[7..0] includes the members FRED[7] down to FRED[0] and also the members FRED7 down to FRED0.

FRED[7] is exactly the same as FRED7 etc.

If you have already independently named a node FRED7 for instance, it will become part of the FRED[7..0] bus - with the bus conflicts/pin renaming you describe.

If you want really confusing fun try naming a bus like FRED372[7..0]

Icky

Use a HDL?

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

The problem isn't with the HDL/Schematic debate, but with the fact that there's a problem in how Quartus interprets the diagram. For a

2k-Gate device, HDL's are nice and simple to use, but for a design with eight 5-M-Gate devices, you want to have a block diagram at some point. Most designs fall between those. Since it's the interpretation of the diagram/schematic that's messed up, you can't very well use HDL to fix it if you ultimately want a block diagram. Another problem arises when you attempt to review a 3000 page HDL design, in that there get to be disagreements between individuals performing the review, and with a BIG design, it means the folks paying for the design have to pay more for the review, which, with HDL, takes 3-4 weeks, while, with schematic/block-diagrams, it takes half a day. Most of the guys I work for are engineers, and even the civil-engineer/ corporate-officers can read and correctly interpret a schematic, while most recent EE grads, who were taught about HDL's still have trouble with a big HDL design. The competent old-timers, the ones paying for the work to be done, just scratch their heads and frown at HDL listings.

The problem is with the documentation, if not with the way in which signal names are interpreted. As far as I'm able to tell there is too little of it, and much of it is out of date or otherwise in conflict with the way in which the software behaves. Since the task is to produce a design that's documented in schematic form, there's little to be done with HDL until the schematic editor works better and the code is brought into sync with the documentation.

Richard Erlacher Erlacher Associates Denver, CO

Icky,

I agree that this is a mess, but the Altera folks have freely declared this to be a bug since v2.2 of Quartus, but it's not due to be remedied until later this year (purportedly in October, when the "next release" is scheduled to occur. I may not understand the rules to which the software was written,but I have read what little avaiable documentation there is and none of the approaches that they propose, nor any of those proposed by the support staff, will work properly.

What puzzles me is that the doc suggests that the bus name should be A[15..0] and another might be D[7..0]. It handles the latter just fine but always makes a mess of the assignments and interpretation of the former. It's done that since the original release of Quartus, and I've complained. The Altera folks claim they're fixing it, but there's room for doubt. Since it's taken them over four years to address the matter.

I have, in my current quest, four named busses, and three are handled exactly as I wish. Why do you think it handles the bus named A[15..0] (yes, STD_LOGIC_VECTOR(15 downto 0);) differently from the other three? What can I do to make it work, in schematic form?

What you said gives me pause, as I'm looking at having to change a bunch of signal names that it presently doesn't screwup, e.g. nOEU6 and nOEU7 ... etc. all of which, as you suggest, should be part of a bus if that's how it works. They're not, however, and don't appear in a group, though all the named busses, aside from the A[15..0] bus, are presented as groups.

I don't generally use Altera parts/software unless I have to have 5- volt logic. I'm using this stuff because I have a number of boards I use and reuse in test fixtures and proof-of-concept stuff and generally don't have data busses to contend with. This case is an exception. All the bus names in this case are similarly constructed, yet the software chooses to mess up one of them. I'd really like to know how to fix this.

Richard Erlacher Erlacher Associates Denver, CO