2

I'm using Lattice Diamond 3.6

The issue I'm having is that I have my code set up to take a bunch of inputs from point A, debounce them, and then forward them to and output at B. Then, it also takes inputs from B, debounces them, and sends them to A.

The point is this is a controller that checks for certain operating conditions, and if something goes sideways, only continues to pass some signals for monitoring.

At this time all the VHDL code is doing is receiving the signals, passing them to a debouncer, retrieving them, and passing them out again. The IDE has also chosen to remove all of these signals. 

Semantic error in "LOCATE COMP "PERIPHERALSOUT(0)" SITE "F15" ;": COMP "PERIPHERALSOUT(0)" cannot be found in design. This preference has been disabled.

The debouncer is NOT the issue, because it's working just fine for a slew of other signals, and there are no errors from that end.

Q: What do I have to do to stop these signals from being omitted and causing a slew of errors and warnings, and likely being deleted from the design?

Morten Zilmer
  • 15,586
  • 3
  • 30
  • 49
T_Poda
  • 51
  • 1
  • 3
  • 1
    Looking at your previous [question](https://stackoverflow.com/questions/36008289/vhdl-arbitrarily-unconnected-components) peripheralsout comes from iperihereals an output of debouncer periph_driver, which has it's input from peripheralsin, a port. Things can get 'eaten' in synthesis is because something isn't connected somewhere. If debouncer is intact, trace the input back to an input pin (in an LPF file?). Spelling can be important. There's a PAD report file for I/O. Show all your errors and warnings. –  Mar 16 '16 at 04:13
  • The port `PERIPHERALSOUT` is an output and should never be optimized away. Of course, it can have a constant value after synthesis optimization. But, tjis would still allow to assign a pin. Either you encounter a tool bug, or something else is setup wrong. – Martin Zabel Mar 16 '16 at 05:56
  • Lattice Diamond removes IOs from the design if these are unused, and that can lead to the error message that you receive. To debug this, maybe try to connect the input directly to the output, to see that the tool will then not remove the IOs. – Morten Zilmer Mar 16 '16 at 06:57
  • 2
    I hate asking questions and then spending several hours trying to debug the problem, when the solution is simple: the cause of the problem was in the *.lpf file: I didn't use square brackets on the vector pin assignments. I'm hitting myself over the head on this one because this was a straightforward solution. SOLUTION: The solution was that I used round brackets instead of square brackets in the LPF file. The change fixed the problem. – T_Poda Mar 16 '16 at 08:54
  • @T_Poda : Nailed it. Frequently, tools issues and all the non-standard scripting languages and so on cause far more problems than the VHDL code itself. And they change between toolchains even from the same company, so they cannot be easily taught in detail. –  Mar 16 '16 at 10:55

0 Answers0