std_logic atau std_ulogic?

24

Tampaknya dunia telah memutuskan bahwa std_logic(dan std_logic_vector) adalah cara default untuk mewakili bit dalam VHDL. Alternatifnya adalah std_ulogic, yang tidak diselesaikan.

Ini mengejutkan saya karena biasanya, Anda tidak menggambarkan bus , jadi Anda tidak ingin banyak pengemudi dan Anda tidak perlu menyelesaikan sinyal. Keuntungannya std_ulogicadalah bahwa kompiler memperingatkan Anda sejak awal jika Anda memiliki beberapa driver.

Pertanyaan: apakah ini hanya masalah budaya / sejarah, atau masih ada alasan teknis untuk menggunakan std_logic?

vhdl Philippe
sumber
3
"Dunia" salah. Insinyur pintar menggunakan std_ulogic karena memiliki semantik yang benar.
wjl
@wjl Saya akan menafsirkannya sebagai "ini adalah budaya / sejarah". Jawaban Anda di bawah ini jauh lebih bermanfaat daripada komentar di sini.
Philippe
Saya menulis komentar terlebih dahulu, kemudian berpikir akan lebih tepat untuk meninggalkan jawaban dengan lebih spesifik. Maaf, saya kira itu terdengar sedikit kurang ajar. Tetapi komentar saya benar-benar berarti bahwa kebanyakan orang mulai menggunakan std_logic karena mereka mempelajarinya seperti itu, kemudian setelah beberapa saat mereka mulai bertanya-tanya tentang std_ulogic, mereka mencarinya, menyadari itu semantik, dan kemudian mengubahnya. =)
wjl

Jawaban:

16

Std_logic adalah subtipe dari std_ulogic dan memiliki tepat satu properti tambahan: itu diselesaikan jika ada beberapa driver.

Terlepas dari praktik umum, std_ulogic adalah tipe yang tepat untuk digunakan untuk sinyal yang tidak diselesaikan yang membutuhkan logika bernilai 9. (Seringkali, menggunakan "bit" bahkan lebih benar - misalnya, pada beberapa arsitektur FPGA yang tidak memiliki 'X' atau 'U').

Pada dasarnya, hal terbaik yang harus dilakukan adalah menggunakan jenis yang tepat untuk pekerjaan itu. Seringkali praktik buruk disebarkan oleh orang-orang yang hanya membeo gaya yang mereka lihat orang lain gunakan, lakukan tanpa memahami alasannya.

wjl
sumber
8
Arsitektur mungkin tidak memiliki 'U', tetapi seringkali berguna untuk mensimulasikan seolah-olah itu terjadi karena Anda dapat menemukan inisialisasi yang salah. Memberi +1 untuk "hal terbaik yang harus dilakukan adalah menggunakan jenis yang tepat untuk pekerjaan itu", tetapi kita cenderung belajar sambil terus tentang apa yang "terbaik" :)
Martin Thompson
8

Riwayat saya adalah ini:

Saya memulai (sekitar tahun 1999 IIRC) menggunakan std_ulogic*semua waktu - karena ini adalah hal yang tepat untuk dilakukan, hanya untuk alasan yang Anda jelaskan.

Lalu saya harus antarmuka ke sekelompok IP vendor yang dihasilkan penyihir yang semuanya memiliki std_logicseluruh antarmuka. Yang berarti konversi pada pemetaan-port (untuk _vectorelemen), dan saya menjadi malas dan pindah ke menggunakan std_logic*.

Namun, saya tampaknya membuat sedikit kesalahan "pengemudi ganda", jadi saya tidak melewatkan std_ulogicsebanyak yang saya kira. Dan driversperintah Modelsim membuatnya sangat mudah untuk menemukan "siapa yang mengemudikan apa" ketika saya sesekali perlu ...

Martin Thompson
sumber
Ya, inti IP (dan terutama hal-hal yang diterjemahkan secara otomatis dari Verilog) cenderung menggunakan std_logic. Jawaban Anda tampaknya menunjukkan bahwa alasannya sebagian besar "budaya / historis".
Philippe
Anda tidak perlu mengonversi antara std_logic dan std_ulogic pada port. Apakah maksud Anda Anda harus mengonversi antara std_logic_vector dan std_ulogic_vector?
wjl
@wjl: maaf, ya itu yang saya maksud. Saya akan memperbarui pos.
Martin Thompson
AFAIK, std_logic dan std_ulogic kompatibel dengan penugasan karena mereka memiliki tipe basis yang sama. Jadi, tidak perlu ada konversi manual.
Val
@ Val: itulah yang dikatakan wjl (dan saya setuju dengan) - tetapi bagian *vectorport masih membutuhkan konversi
Martin Thompson
4

IIRC std_logic(_vector), yang direkomendasikan sebagai Metodologi Manual Penggunaan Kembali , jadi mungkin grup metodologi di perusahaan dll menyebar lebih jauh dalam bentuk panduan kode (wajib). Secara pribadi, +1 untuk digunakan std_ulogicbila memungkinkan.

cmarqu
sumber