Forum Discussion
Altera_Forum
Honored Contributor
15 years ago --- Quote Start --- I also forgot to mention the difficulty simulating schematic designs. Its fine just using the "convert to HDL" feature, but what about when I want to test a design in isolation using models for other design parts for extra speed of simulation? and also what happens when a company drops support for some schemtic elements, or schematics altogether (like the LPM library in quartus schematics). You're stuck using an old version, or if a company goes bust - no software at all! --- Quote End --- An open core project may remove the dependence on vendors and provide a tool for the front end design. It would also be a cooperative effort where users could get involved in defining the tool, rather than sitting back and whining when vendors don't come through. This site has a prototype/demo simulator and logic for a simple ring test case. As fast and simple as I can imagine. http://mysite.verizon.net/vzeosqt4/booleassignexpressions I think getting some quick simulation is valuable to at least get waveforms for documentation. Also it should be rather easy to text edit the input to run part of the design at high level and another part at detailed level which I think is your first question. I have not tried to do that, though. The rest of this is some random thoughts and a sketchy explanation of the syntax. We really do not need a .bdf, but some kind of block diagram is useful to show the functions in a thing. Things are made from other things in a hierarchy. Things have names and qualified names are used to navigate hierarchies. Things can store numbers, manipulate pairs of numbers, can be triggered, and the triggering can be conditional. The conditional input can come from a network of and/or/not blocks, a series of if/else statements. It could also be Boolean Logic. Boolean is text, concise and easily evaluated. Chips are clocked and each clock has its domain. Organizing design input so that all the blocks triggered by the clock maybe enclosing in curly braces, is analogous to a block of code following an if statement is more concise than specifying the clock over and over for each always or block input. Here a '\' designates a clock def. Arrays and bit fields use square bracket as hdl's do. Suggested syntax is reg_name : value ? condition reg_name is a register, counter, array if reg_name[address], shift reg, or bus etc value is a number, reg_name, bus name condition is a Boolean combination of signals which may be reg bits, etc Using block_name._reg_name for a hierarchical design seems useful. Signals use a leading underscore in the name and are evaluated when used. // comment clk.0 @ 0.2 // set to 0 at time 0 repeated at intervals of 2 clk.1 @ 1.2 // set to 1 at time 1 repeated at intervals of 2 == oscillator \c1?!clk c1 is a two phase clock with phase 1 driven by the clk oscillator. \c2?1 // c2 is phase two(hot, always true) so the din immediately appears at qout // Allows various clocking schemes, this example is a single phase, logically